Internet Engineering Task Force P. Savola Internet Draft CSC/FUNET Expiration Date: April 2004 October 2003 A View on IPv6 Transition Architecture draft-savola-v6ops-transarch-01.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 April 2004] [Page 1] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 Table of Contents 1. Introduction ............................................... 2 2. Architectural Considerations ............................... 3 2.1. General Principles ..................................... 3 2.2. Architecting the Transition ............................ 4 2.2.1. Mechanisms, Deployment Models, and Services ........ 4 2.2.2. Implications ....................................... 5 2.3. Transition Mechanism Deployment Considerations ......... 6 3. Transition Mechanism Considerations ........................ 6 3.1. Obtaining Connectivity ................................. 6 3.2. Protocol Translation ................................... 7 3.3. Application Level Gateway or Proxy ..................... 7 4. A View on Transition ....................................... 8 4.1. The Cost of Dual-stack Compared to IPv6-only ........... 8 4.2. Generic Protocol Translation in IPv6 ................... 9 4.3. Providing IPv6-enabled Services ........................ 9 4.4. Deployment of IPv6-only Nodes .......................... 10 4.5. Deploying IPv6-only Sites .............................. 10 4.6. The Role of an IPv6 ISP ................................ 11 4.7. Example: TCP/UDP Relay ................................. 11 5. Acknowledgements ........................................... 12 6. Security Considerations .................................... 12 7. References ................................................. 12 7.1. Informative ............................................ 12 Author's Address ............................................... 12 Intellectual Property Statement ................................ 12 Full Copyright Statement ....................................... 13 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" Savola [Expires April 2004] [Page 2] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 comes from transitioning from IPv4-only networks to networks where IPv6 has been enabled. 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. Savola [Expires April 2004] [Page 3] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 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. 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 Savola [Expires April 2004] [Page 4] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 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: +---------+---------+--------+------+---------+ |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. Savola [Expires April 2004] [Page 5] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 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? 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) to 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 classified in several ways, but here is one: Savola [Expires April 2004] [Page 6] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 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. 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 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. 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, and the applications, must be explicitly configured unless automated somehow. 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. Savola [Expires April 2004] [Page 7] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 4. A View on Transition This section includes a few views on several aspects of the transition. 4.1. The Cost of Dual-stack Compared to IPv6-only An oft-cited argument against deploying dual-stack instead of IPv6-only and 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 are routing protocols which allow a single Shortest Path First (SPF) calculation for both IP protocols; routing protocols which allow transporting routing advertisements of both IP versions on a single session, etc. -- 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 -- in any case, the use of an IPv4 NAT or a protocol translator would result in a similar set of end-to-end transparency problems for IPv4. 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 only addressing related concern seems to be being able to avoid the paperwork towards 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 especially in some more evolved networks. However, this seems counter-productive. 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 interoperate with IPv6 nodes. Generic translation is not necessary, and at most some form of simple application proxying is used. When/if there emerge, they could be deplyed in an IPv6-only fashion .. but still, the network would be dual-stack. It might be that this stanza could change radically in (say) 10 years if the deployment gets off, but prior to major global deployment Savola [Expires April 2004] [Page 8] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 happens (e.g., causing over 3/4 of services be available over IPv6), any action towards generic IPv6-only seems premature. 4.2. Generic Protocol Translation in IPv6 One argument for generic protocol translation (not just 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 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 of its own. In this light, it is more desirable to just continue using IPv4 when needed, and keeping IPv6 as "high quality". 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. 4.3. 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 general, this is a relatively safe mechanism, Savola [Expires April 2004] [Page 9] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 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 is globally stable and robust IPv6 connectivity. It seems to take long until that is achieved [6BMESS]. 4.4. 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. Some services can easily be provided through separate services or proxies 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.5. 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/proxy 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. Savola [Expires April 2004] [Page 10] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 The fixes to this are similar; first, the proxies or translators could be designed to prefer IPv4 services by default until explicitly configured otherwise: then even IPv6-enabled services would be reached using IPv4. 4.6. 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. 4.7. 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. 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. Savola [Expires April 2004] [Page 11] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 5. 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. 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. [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 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 Savola [Expires April 2004] [Page 12] Internet Draft draft-savola-v6ops-transarch-01.txt October 2003 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 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 April 2004] [Page 13]