Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: August 2003 February 2003 A View on IPv6 Transition Architecture draft-savola-v6ops-transarch-00.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-existance of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches. Savola [Expires August 2003] [Page 1] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 Table of Contents 1. Introduction ............................................... 2 2. Architectural Considerations ............................... 3 2.1. General Principles ..................................... 3 2.2. Architecting the Transition ............................ 3 2.2.1. Mechanisms, Deployment Models, and Services ........ 4 2.2.2. Implications ....................................... 4 2.3. Transition Mechanism Deployment Considerations ......... 5 3. Transition Mechanism Considerations ........................ 6 3.1. Obtaining Connectivity ................................. 6 3.2. Protocol Translation ................................... 7 3.3. Application Level Gateway .............................. 7 3.4. Application Proxy ...................................... 7 4. A View on Transition ....................................... 7 4.1. Providing IPv6-enabled Services ........................ 8 4.2. Deployment of IPv6-only Nodes .......................... 8 4.3. Deploying IPv6-only Sites .............................. 9 4.4. The Role of an IPv6 ISP ................................ 9 4.5. Example: DSTM .......................................... 10 4.6. Example: TCP/UDP Relay ................................. 10 5. Acknowledgements ........................................... 11 6. Security Considerations .................................... 11 7. References ................................................. 11 7.1. Informative ............................................ 11 Author's Address ............................................... 11 1. Introduction The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is a subject of much debate. However, the big picture of the transition seems not to have been discussed sufficiently. Therefore, different people have different assumptions on the process, which makes planning the transition architecture very difficult: indeed, it seems that there is a lack of architecture in the transition process. This memo tries to point out some issues that will need consideration in the transition architecture, as well as point out a few personal views on certain transition approaches. As a semantic note, "IPv6 Transition" here is used to refer to the process of enabling the use of IPv6. In practise, the first stage is mostly IPv4/IPv6 dual-stack co-existence. The term "transition" comes from transitioning from IPv4-only networks to networks wehre IPv6 has been enabled. Savola [Expires August 2003] [Page 2] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 2. Architectural Considerations 2.1. General Principles General principles which should be carefully considered when architecturing the transition include at least: o security o simplicity o robustness Actually, all of these are somewhat related; similar has also been noted in the Internet architectural principles [ARCH]. Security is very important: deploying transition mechanisms must not enable significant security holes, 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 practises which have clear uses -- 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. Also, mechanisms must not be less robust than their IPv4 counterparts: quite the contrary. It is highly desirable to aim for building the architecture which does not depend on known-unreliable components (for example, certain operational modes of IPv4 NAT's); otherwise, the whole architecture is easily deemed unreliable. 2.2. Architecting the Transition There has to be some form of plan how the IPv6 transition is to be done. In absence of a plan, the transition must be made so that the future transition options will not be end-ran, and only "safe" transitionary actions are executed. For example, deploying dual-stack nodes with currently only IPv4 connectivity does not end-run any transitionary goals, but is an important step that must be done anyway. Savola [Expires August 2003] [Page 3] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 2.2.1. Mechanisms, Deployment Models, and Services When forming a transition architecture, there are typically different building blocks to be used, from different classes, including: Mechanisms: o Providing IPv6 connectivity o Protocol translation o Application-specific protocol interoperability (ie. ALG or proxy) Deployment models for IP nodes: o IPv4-only o Dual-stack with only IPv4 connectivity o Dual-stack w/ IPv4/6 connectivity o Dual-stack with only IPv6 connectivity o IPv6-only And services: o IPv4-only o Separate IPv4 and IPv6 o IPv4/6 o IPv6-only In above, "Separate" 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 IPv4 SMTP mail exchange (MX) service for IPv6-only sites, or the like; note that "separate" could be considered to include an application level gateway of a sort. One should be wary when deploying "Separate" or "IPv4/6" services. Both have their advantages and disadvantages, which depend heavily on the stage of the transition. Namely, some forms of separate services are often more difficult to manage and troubleshoot, and there is the problem of service getting out-of-sync; on the other hand, deploying IPv4/6 services before IPv6 connectivity is stable enough has it's own severe disadvantages, as will be pointed out in the following sections. 2.2.2. Implications From the three categories listed above, one can note that you will only need to go to the first, mechanisms, category if the last two do not give satisfying combinations. That is: Savola [Expires August 2003] [Page 4] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 +---------+---------+--------+------+---------+ |Modl\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 unoptimal, as they do not progress the transition. To summarize, in the generic case, when someone providing service is not sure who will be using it, then the service should not be deployed IPv4-only or IPv6-only. Also, when someone is planning a deployment of nodes, if one is not sure which services they will be using, the nodes should not be deployed IPv4-only, dual-stack with only IPv6 connectivity or IPv6-only. However, in some cases sticking to this guideline is not enough, and something more is needed. 2.3. 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 deploy IPv6-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 nodes, or dual-stack nodes with only IPv6 connectivity, whose burden is it to enable them to access all the services they want? Savola [Expires August 2003] [Page 5] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 o how much easier would it be to go for dual-stack approach instead? The intuitive answer to both of these would appear to be: "if you really want to shoot yourself in the foot, do not blame the person who sold you the gun -- or at least get prepared for a big hospital bill." That is, 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 these issues yourself -- or get someone else (e.g. a service provider providing extra IPv6 services) do it. Of course, when considering an option like this, one should always be double careful not to forget comparing the situation to the cost of deploying a dual-stack solution. Typically, it would appear to be the case that a dual-stack solution is much easier to cope with than the alternative, and the total cost is less. 3. Transition Mechanism Considerations 3.1. Obtaining Connectivity As noted in the matrix in the previous chapter, dual-stack approach (using one of the flavours) seems vastly superior in the generic case. 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 later). The connectivity could be classied 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) 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. Savola [Expires August 2003] [Page 6] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 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. 3.3. Application Level Gateway An ALG may actually implement a translation function, as described above, but it is specifically deployed in such a fashion that the translation is only applied to the applications that should work with a relatively high expectation of success. A typical disadvantage of ALG's is that their use, and the applications, must be explicitly configured. This is not always the case, and the mechanisms could be developed towards that direction, too. 3.4. Application 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. 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. Of course, this is not a general solution, but if such a proxy is co- located with a firewall, and covers all protocols allowed by the firewall, there should be no impact on users. beyond the usual effects of the firewall. 4. A View on Transition This section includes a few views on several aspects of the transition. Savola [Expires August 2003] [Page 7] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 4.1. Providing IPv6-enabled Services 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 use or applications significantly. 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. 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 some cases, this may severely affect the outbound connections and cannot be done. However, 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 subdomain. 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 requirement for this problem to go away are globally stable and robust IPv6 connectivity. It seems to take long until that is achieved [6BMESS]. 4.2. Deployment of IPv6-only Nodes There are several issues associated with deploying IPv6-only (or in most cases, also dual-stack w/ IPv6-only connectivity) nodes. In particular, the question about the mechanism to access IPv4 services will be asked; it can be avoided by "don't do it then, yet", but at some point (sooner or later), there will be a desire to deploy IPv6-only nodes. Savola [Expires August 2003] [Page 8] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 Some services can easily be provided through separate services or ALG's through dual-stack nodes crafted for this purpose, or the IPv6 ISP: for example, dual-stack DNS recursive resolvers, SMTP MX services, WWW-caches, and others. In some ways, this has the similar conditions as the case above: a sufficient amount of IPv6 connectivity of *good quality* is required, as well as a way to access IPv4 services (in the general case). 4.3. Deploying IPv6-only Sites The above two cases have already shown problems with IPv6-only deployments, but here issues specific to IPv6-only sites are discussed. It is not enough to deploy IPv6 architecture internal to the site and to provide translation/ALG service to make it possible to reach mainstream IPv4 services. This is because this will lead to a service outage or degradation when trying to reach services in the Internet which are IPv6-enabled, *unless* the network connectivity is good enough (at least near IPv4 quality) to the majority of the IPv6-enabled destinations, due to the reasons described above. The fixes to this are similar; first, the ALG's or translations could be designed to prefer IPv4 services by default until explicitly configured otherwise: then even IPv6-enabled services would be reached using IPv4. 4.4. The Role of an IPv6 ISP Previously, it has been stated that IPv6-enabled ISP's could provide a certain set of solutions, in particular, in cases where the sites try to reach an IPv6-state. It should be noted that there are ISP's operating under different models: some do not want to produce much other than IPv4/v6 -enabled connectivity. Some may only provide IPv6-connectivity. However, in the latter case, it is quite probable that the ISP is also willing to provide services that make the life of IPv6-only users easier. Savola [Expires August 2003] [Page 9] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 4.5. Example: DSTM [DSTM] offers a mechanism of deploying IPv6-only network infrastructure with dual-stack nodes with only IPv6-connectivity; IPv4 addresses are assigned temporarily on need, and transported to the tunnel end-point inside the site. This offers the advantage of removing the IPv4 addressing and routing from the most parts of the site. However, these already exist (in older deployments), or can rather easily be configured according to the IPv6 routing/addressing plan. The major drawbacks include the temporarity of address assignment, and questionable observed advantages. It seems that the cost of deploying IPv4 addresses and routing in the site-internal network infrastructure is very low; actually current platforms do not even work without it. So, the model appears to be both premature and questionable. Also, the temporary address assignment would seem to conflict with the robustness and simplicity principles: it may be very difficult to make such an operation work flawlessly; the basic operation could be much simpler -- constant IPv4 address assigned -- but then a perceived advantage of the mechanism would be lost. 4.6. Example: TCP/UDP Relay [RELAY] provides a mechanism to perform protocol translation 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 of protocol translation and DNS. However, on the server side, it is much simpler. 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 towards 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. Savola [Expires August 2003] [Page 10] Internet Draft draft-savola-v6ops-transarch-00.txt February 2003 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 for some IPv4-enabled services to the IPv6 users. 5. Acknowledgements Discussions with Brian Carpenter gave a push to writing this memo. 6. 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. 7. References 7.1. Informative [6BMESS] Savola, P., "Moving from 6bone to IPv6 Internet", draft-savola-v6ops-6bone-mess-01.txt, work-in-progress, November 2002. [ARCH] Bush, R., Meyer, D., "Some Internet Architectural Guidelines and Philosophy", RFC3439, December 2002. [DSTM] Bound, J., et al., "Dual Stack Transition Mechanism", draft-ietf-ngtrans-dstm-08.txt, expired work-in-progress, July 2002. [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 Savola [Expires August 2003] [Page 11]