IPv6 Operations F. Baker Internet-Draft Cisco Systems Expires: February 13, 2006 August 12, 2005 The End to End Problem in a fully generalized IPv4, IPv6, and IPv4+IPv6 network draft-baker-v6ops-end2end-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 13, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This note is intended to describe the end to end problem as it applies to a network of networks, wherein some component networks independently run only IPv4 with or without a transition mechanism, some run only IPv6 with or without a transition mechanism and without coordination of transition mechanisms, and some run IPv4 and IPv6 in parallel supporting native routing. Baker Expires February 13, 2006 [Page 1] Internet-Draft The End to End Problem in Transition August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Transition, and transition problems . . . . . . . . . . . . . 4 2.1 A provably correct transition plan . . . . . . . . . . . . 4 2.2 The IPv4 rendezvous problem . . . . . . . . . . . . . . . 6 2.3 The IPv6 rendezvous problem . . . . . . . . . . . . . . . 6 2.4 And then there is multicast... . . . . . . . . . . . . . . 7 3. End to end arguments in transition design . . . . . . . . . . 8 3.1 The end to end problem in IPv6 over or in IPv4 . . . . . . 8 3.2 The end to end problem in IPv4 over or in IPv6 . . . . . . 9 3.3 Mutual encapsulation considered bizarre . . . . . . . . . 10 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . 16 8.3 More Informative References . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 A. Requirements for a general transition strategy . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 23 Baker Expires February 13, 2006 [Page 2] Internet-Draft The End to End Problem in Transition August 2005 1. Introduction This note is intended to describe the end to end problem as it applies to a network of networks, wherein some component networks independently run only IPv4 with or without a transition mechanism, some run only IPv6 with or without a transition mechanism and without coordination of transition mechanisms, and some run IPv4 and IPv6 in parallel supporting native routing. This is to say that the IETF recommendations in [RFC2893] and [RFC4029] are not necessarily implemented during IPv6 deployment, and this creates issues for the Internet as a whole. [RFC1958] states that Many members of the Internet community would argue that there is no architecture, but only a tradition, which was not written down for the first 25 years (or at least not by the IAB). However, in very general terms, the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network. The current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web. This connectivity requires technical cooperation between service providers, and flourishes in the increasingly liberal and competitive commercial telecommunications environment. The key to global connectivity is the inter-networking layer. The key to exploiting this layer over diverse hardware providing global connectivity is the "end to end argument". This note starts from those key observations, including the End to End Argument (which will be spelled out in Section 3), and raises a very deep concern about the wild proliferation of mutually incompatible transition strategies with little or no useful guidance from the networking community. Baker Expires February 13, 2006 [Page 3] Internet-Draft The End to End Problem in Transition August 2005 2. Transition, and transition problems Much has been written about possible transition scenarios, and about the transition from an IPv4 to an IPv6 Internet. [RFC2185], which is somewhat dated, comments on the Routing Aspects of the transition. [RFC2893] proposes basic Transition Mechanisms. [RFC3574] comments on the Transition Scenarios for 3GPP Networks. [RFC3750] looks at unmanaged networks, and [RFC3904] evaluates that approach. [RFC4038] comments on the application issues. Numerous other documents look at specific transition scenarios and propose various ways to translate between IPv4 and IPv6 in a gateway at the network layer, tunnel IPv4 over IPv6 or IPv6 over IPv4, and rendezvous between systems of either type over networks running the other. 2.1 A provably correct transition plan A provably correct algorithm, in mathematical terms, is one for which a proof can be presented demonstrating that it works without error in all cases. It is not exclusive: there may also be other algorithms that work correctly, and the fact may or may not be readily proven. The IETF's current recommendation, originally proposed in [RFC1933] and now documented in [RFC2893] is that the best possible transition mechanism envisions these steps: 1. The basic network runs IPv4 forwarding and routing. 2. IPv6 forwarding and routing is added to that network, either by tunneling IPv6 over IPv4 or by directly bringing IPv6 forwarding and routing up in parallel with the IPv4 network. 3. Applications determine whether IPv6 connectivity is available between them, and if so use it; otherwise, they default to IPv4, which is presumed to work. 4. A market develops, driving IPv6 deployment to also become essentially ubiquitous. The key steps in this development include * administrations obtaining and deploying IPv6 address space, perhaps in response to increasingly stringent IPv4 prefix allocation guidelines or diminishing allocation availability, * business drivers toward end to end connectivity that are not readily solved using NAT traversal techniques, * some edge networks administrations deploying only IPv6, and Baker Expires February 13, 2006 [Page 4] Internet-Draft The End to End Problem in Transition August 2005 * other administrations needing to communicate with the IPv6- only administrations or using IPv6-only applications. 5. At some point in the (very) distant future, IPv6 connectivity is sufficiently ubiquitous that IPv4 connectivity becomes unnecessary. At this point, businesses independently remove IPv4 from the network as being no longer useful. Within a single administration, one could imagine that central IPv4 network being instead an IPv6 network with IPv4 connectivity provided over it by tunneling. Within a single administration, this is workable, as the administration is in control of all access to that network and the basic paradigm is preserved (IPv4 connectivity is ubiquitous and IPv6 connectivity is growing). The key point is that at the network edge, IPv4 and IPv6 always run natively, providing robust IPv4 services until IPv6 becomes ubiquitous, and after that robustly provides IPv6 connectivity, and other transition mechanisms if used operate within a single administration. A network connecting IPv6 over an IPv4 core is as shown in Figure 1. The gateways may be provided by the central network or by its clients; the key point is that they interoperate. ,---. ,---. ,' `. ,' `. / \ / \ / \ / \ ; IPv6+IPv4 : ; IPv4 : | Network | | Network | : ; ,---. : ; \ +----+,' `.+--\ / \ | GW | \ R \ / `. ,+----+ \---+`. ,' '---' : IPv4 : '---' | Network | ,---. : ; ,---. ,' `.+--\ +----+,' `. / \ R \ | GW | \ / \---+`. ,'+----+ \ ; IPv4 : '---' ; IPv6+IPv4 : | Network | | Network | : ; : ; \ / \ / \ / \ / `. ,' `. ,' '---' '---' Figure 1: An end to end IPv4 network with potential IPv6 connectivity Baker Expires February 13, 2006 [Page 5] Internet-Draft The End to End Problem in Transition August 2005 This is not without risk; there is concern in some sectors that relatively new IPv6 services might destabilize IPv4 services in a domain. However, it is provably correct. There may or may not be IPv6 connectivity between any two points in the network, but if the entire network is running and routing IPv4, there is at minimum IPv4 connectivity. 2.2 The IPv4 rendezvous problem If static tunneling of IPv6 traffic over an IPv4 infrastructure, such as the 6bone, is used, routing IPv6 through the tunnels is not hard. There is a problem in the second step, however, if dynamic tunneling (or translation) is used; there must be some means for a system on one side of an IPv4-only domain to determine the ingress and egress gateways between which to tunnel. The ingress and egress systems must, of course, interoperate, and must provide a path that gets traffic between the relevant endpoints. Various approaches have been suggested, including o advertising DNS names of end systems with the addresses of translators between naming domains [RFC2694][RFC2766], o Automated Tunneling [RFC3056], o Translating IPv4 addresses to IPv6 addresses in IPv6 routing [RFC3513] section 2.5.5, o Tunnel Brokers [I-D.blanchet-v6ops-tunnelbroker-tsp], o The use of an address server to determine the appropriate egress gateway address from the ingress gateway or end system[I-D.bound- dstm-exp], o The use of an address server to interconnect IPv4 NATs [I-D.liumin-v6ops-silkroad], o and a variety of others. 2.3 The IPv6 rendezvous problem At this point, various administrations are deploying or considering deploying IPv6-only or what are called "IPv6-dominant" networks. An IPv6-dominant network is one that internally routes only IPv6 and perhaps only forwards IPv6, and provides IPv4 services by tunneling or translation to IPv6. The problem noted in the preceding paragraph applies equally to such networks; there must be a way to establish IPv4 routes over the intervening IPv6 network, and if dynamic Baker Expires February 13, 2006 [Page 6] Internet-Draft The End to End Problem in Transition August 2005 tunneling is used, there must be a way to dynamically determine the appropriate ingress and egress gateways. 2.4 And then there is multicast... There is a saying in IETF circles concerning routing, which is the issue addressed in this document. "There is a simple test that will tell whether one understands a given routing problem adequately, and whether a given solution is adequate to cover the routing issues. Simply repeat the sentence used to describe the solution using the word 'Multicast'". There is need for additional transition work regarding deployment of IPv6 multicast. Baker Expires February 13, 2006 [Page 7] Internet-Draft The End to End Problem in Transition August 2005 3. End to end arguments in transition design In [Saltzer], Saltzer and Reed discussed a fundamental argument, which they call the End to End Argument. This has been stated in many ways, but at its simplest it states that unnecessary complexity in a network results in side-effects that decrease performance, reduce functionality, and in the worst case cause the system to fail in some way. The paper argues that unnecessary network complexity is to be avoided, leaving maximum flexibility to the end system to innovate and change. "A satisfactory solution", it could be said, "contains no unnecessary complexity", and "first, does no harm." 3.1 The end to end problem in IPv6 over or in IPv4 Figure 2 shows a network that has multiple transition strategies for IPv6 connectivity. Granting that each transition strategy works in isolation, and therefore the two IPv6 networks connected via transition strategy A inter-work and the two IPv6 networks connected via transition strategy B inter-work, it is not obvious that all four IPv6 networks inter-work. ,---. ,---. ,' `. ,' `. / \ / \ / \ / \ ; IPv6+IPv4 : ; IPv6+IPv4 : | Network | | Network | : ; ,---. ,---. : ; \ +----+,' `. ,' `.+----+ / \ |GW-A| \ / |GW-B| / `. ,+----+ \ / +----+`. ,' '---' : IPv4 :: IPv4 : '---' | Network || Network | ,---. : Transition ;: Transition : ,---. ,' `.+----+ Strategy / \ Strategy +----+,' `. / |GW-A| A / \ B |GW-B| \ / +----+`. ,' `. ,'+----+ \ ; IPv6+IPv4 : '---' '---' ; IPv6+IPv4 : | Network | | Network | : ; : ; \ / \ / \ / \ / `. ,' `. ,' '---' '---' Figure 2: An end to end network with multiple support strategies for IPv6 Baker Expires February 13, 2006 [Page 8] Internet-Draft The End to End Problem in Transition August 2005 The problem is, of course, that the transition strategies are not necessarily compatible. Imagine, for example, that strategy A depends on routing to distribute the IPv4 addresses of edge dual stack routers, enabling them to dynamically create tunnels as needed, while strategy B depends on DNS for this function. While both of the IPv4 cores are providing IPv6 transition services, neither will directly interoperate with the other. If the central IPv4 networks are providing the transition strategy, they have the opportunity to bridge the two together. The means to do this is unspecified, however, and may be problematic. In the example just given, one domain might have to poll all names in the other domain in order to map the addresses. If the transition strategies are implemented by the edge networks around the IPv4 domains, however, they will be unaware of the other part of the network and will not know to translate. For them, the only option is to provide both transition strategies (BGP NHRP-like extensions *and* DNS lookups) in their gateways and perform the correct transition for any given address - which they can only do if they know the difference between routes from different domains. In the early stages of the transition plan mentioned in Section 2, this is perfectly acceptable. During the interval in which IPv6 connectivity is not guaranteed end to end, there is no expectation of such a guarantee. IPv4 continues to operate end to end, and that is sufficient during the early stages of the transition. 3.2 The end to end problem in IPv4 over or in IPv6 Figure 3 Addresses the mirror issue raised in Section 2.3. As in Section 3.1, it shows a network that has multiple transition strategies for IPv4 connectivity over intervening IPv6 networks. Granting that each transition strategy works in isolation, and therefore the two IPv4 networks connected via transition strategy A inter-work and the two IPv4 networks connected via transition strategy B inter-work, it is not obvious that all four IPv4 networks inter-work. Baker Expires February 13, 2006 [Page 9] Internet-Draft The End to End Problem in Transition August 2005 ,---. ,---. ,' `. ,' `. / \ / \ / \ / \ ; IPv6+IPv4 : ; IPv6+IPv4 : | Network | | Network | : ; ,---. ,---. : ; \ +----+,' `. ,' `.+----+ / \ |GW-A| \ / |GW-B| / `. ,+----+ \ / +----+`. ,' '---' : IPv6 :: IPv6 : '---' | Network || Network | ,---. : Transition ;: Transition : ,---. ,' `.+----+ Strategy / \ Strategy +----+,' `. / |GW-A| A / \ B |GW-B| \ / +----+`. ,' `. ,'+----+ \ ; IPv6+IPv4 : '---' '---' ; IPv6+IPv4 : | Network | | Network | : ; : ; \ / \ / \ / \ / `. ,' `. ,' '---' '---' Figure 3: An end to end network with multiple support strategies for IPv4 Once again, the transition strategies are not necessarily compatible. If, for example, strategy A depends on a tunnel server between IPv4 NATs around an IPv6 core, and strategy B depends on distribution of the IPv6 address of the gateway in BGP, IPv4 connectivity across the combined IPv6 domains will be problematic. In the final stages of the transition plan mentioned in Section 2, this is perfectly acceptable. At the point where IPv4 support becomes a lower business priority, IPv6 connectivity is presumed to exist end to end, and there is no longer a need, and therefore no continuing expectation, of such a guarantee. IPv6 continues to operate end to end, and that is sufficient during the final stages of the transition. 3.3 Mutual encapsulation considered bizarre Figure 4 shows the network this author greatly fears that we are in the process of building. It combines the worst parts of Section 3.1 with the worst effects of Section 3.2, resulting in a network in which neither IPv4 nor IPv6 connectivity is guaranteed between any two points. Baker Expires February 13, 2006 [Page 10] Internet-Draft The End to End Problem in Transition August 2005 ,---. ,---. / \ / \ / \ / \ ; IPv4+6 : ; IPv4+6 : | Network | | Network | : +----+---. ,---. ,---. ,---+----+ ; \ |GW-A| \ / \ / \ / |GW-D| / \ +----+ +----+ \ / +----+ +----+ / `---' ; IPv6 |GW-B| IPv4 : ; IPv4 |GW-C| IPv6 : `---' | Network+----+Network | | Network----+Network | ,---. :Transition :Transition :Transition :Transition ,---. / +----+A / \ B / \ C / \ D+----+ \ / |GW-A| / \ / \ / \ |GW-D| \ ; IPv4+6+----+--' `---' `---' `--+----+IPv4+6 : | Network | | Network | : ; : ; \ / \ / \ / \ / `---' `---' Figure 4: An end to end network with multiple transition strategies The problem is that there is a continuing requirement for some form of connectivity, whether IPv4 or IPv6, but neither can be guaranteed in such a network. The trap here is local optimizations for what some might consider to be an isolated network. While each individual local optimization may work in isolation, there is no guarantee that the network of networks it uses as its context works, and therefore its connectivity or the connectivity of others may be limited by the choices it makes. Baker Expires February 13, 2006 [Page 11] Internet-Draft The End to End Problem in Transition August 2005 4. Recommendation In the opinion of this writer, Section 2 provably works despite the kinds of problems raised in Section 3.1 or Section 3.2. The problems those sections raise result from the complexities in the network related to the transition strategies in use, which from the perspective of the argument in [Saltzer] are unnecessary complexities that result in a failure of the network to deliver connectivity. The problems that extra complexity causes are acceptable only because connectivity is in fact guaranteed in another way. In comparison, Section 3.3 provably fails to guarantee connectivity by either IPv4 or IPv6. The "unnecessary complexities" tolerated by Section 3.1 overwhelm the network to cause utter connectivity failure. As a result, although "current exponential growth of the network seems to show that connectivity is its own reward, and is more valuable than any individual application such as mail or the World-Wide Web", the network we are well on our way to creating fails to deliver that fundamental characteristic. This transition non- plan, through negligence, fails the "do no harm" test. In the mind of this writer, therefore, the scenarios contemplated in Section 3 are to be avoided at all costs. Rather than allowing a proliferation of incompatible transition approaches, the IETF must recommend a provably correct transition approach that supports Section 2 throughout each of its steps. Baker Expires February 13, 2006 [Page 12] Internet-Draft The End to End Problem in Transition August 2005 5. IANA Considerations This memo adds no new IANA considerations. Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author's perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion. Baker Expires February 13, 2006 [Page 13] Internet-Draft The End to End Problem in Transition August 2005 6. Security Considerations One could view the problem analysis that is at the heart of this document as a security consideration. In any event, the document does not create new problems. It points out a set of problems that already exist. Baker Expires February 13, 2006 [Page 14] Internet-Draft The End to End Problem in Transition August 2005 7. Acknowledgements Detailed comments were received from Dave Green, Dave Ward, Pekka Savola, Ralph Droms, Steve Klynsma, Stig Venaas, and Tim Chown. Dave Green suggested the text found in Appendix A. Baker Expires February 13, 2006 [Page 15] Internet-Draft The End to End Problem in Transition August 2005 8. References 8.1 Normative References [RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2185] Callon, R. and D. Haskin, "Routing Aspects Of IPv6 Transition", RFC 2185, September 1997. [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. [Saltzer] Saltzer, JH. and DP. Reed, "End-to-end arguments in system design", ACM Transactions on Computer Systems (TOCS) v.2 n.4, p277-288, Nov 1984. 8.2 Informative References [I-D.blanchet-v6ops-tunnelbroker-tsp] Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-02 (work in progress), May 2005. [I-D.bound-dstm-exp] Bound, J., "Dual Stack IPv6 Dominant Transition Mechanism (DSTM)", draft-bound-dstm-exp-03 (work in progress), July 2005. [I-D.liumin-v6ops-silkroad] Min, L., "Tunneling IPv6 with private IPv4 addresses through NAT devices", draft-liumin-v6ops-silkroad-03 (work in progress), July 2005. [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. [RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. Baker Expires February 13, 2006 [Page 16] Internet-Draft The End to End Problem in Transition August 2005 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003. [RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004. [RFC3904] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks", RFC 3904, September 2004. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. 8.3 More Informative References [I-D.despres-v6ops-transition-v5roadmap] Despres, R., "The v5 Approach for the Transition from IPv4 to IPv6", draft-despres-v6ops-transition-v5roadmap-00 (work in progress), July 2005. [I-D.huitema-v6ops-teredo] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-05 (work in progress), April 2005. [I-D.ietf-v6ops-3gpp-analysis] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", draft-ietf-v6ops-3gpp-analysis-11 (work in progress), October 2004. [I-D.ietf-v6ops-ent-analysis] Bound, J., "IPv6 Enterprise Network Analysis", draft-ietf-v6ops-ent-analysis-03 (work in progress), July 2005. [I-D.ietf-v6ops-ipsec-tunnels] Savola, P., "Using IPsec to Secure IPv6-in-IPv4 Tunnels", draft-ietf-v6ops-ipsec-tunnels-00 (work in progress), July 2005. Baker Expires February 13, 2006 [Page 17] Internet-Draft The End to End Problem in Transition August 2005 [I-D.ietf-v6ops-mech-v2] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-07 (work in progress), March 2005. [I-D.ietf-v6ops-natpt-to-exprmntl] Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work in progress), July 2005. [I-D.jaehwoon-dstm-multitep] Lee, J., "Multiple TEP Extension to DSTM", draft-jaehwoon-dstm-multitep-02 (work in progress), July 2005. [I-D.lee-v6ops-natpt-mobility] Shin, M. and J. Lee, "Considerations for Mobility Support in NAT-PT", draft-lee-v6ops-natpt-mobility-01 (work in progress), July 2005. [I-D.massar-v6ops-heartbeat] Massar, J., "SixXS Heartbeat Protocol", draft-massar-v6ops-heartbeat-01 (work in progress), June 2005. [I-D.massar-v6ops-tunneldiscovery] Massar, J., "IPv6 Tunnel Discovery", draft-massar-v6ops-tunneldiscovery-00 (work in progress), July 2005. [I-D.ooms-v6ops-bgp-tunnel] Clercq, J., "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE)", draft-ooms-v6ops-bgp-tunnel-05 (work in progress), May 2005. [I-D.palet-v6tc-goals-tunneling] Palet, J., "Goals for Tunneling Configuration", draft-palet-v6tc-goals-tunneling-00 (work in progress), February 2005. [I-D.parent-v6tc-protocol-exploration] Parent, F., "v6tc Protocol Exploration", draft-parent-v6tc-protocol-exploration-00 (work in progress), December 2004. [I-D.reddy-dhcpv6-opt-dstm-exp] Reddy, A. and J. Bound, "Dual Stack Transition Mechanism Baker Expires February 13, 2006 [Page 18] Internet-Draft The End to End Problem in Transition August 2005 (DSTM) Options for DHCPv6", draft-reddy-dhcpv6-opt-dstm-exp-00 (work in progress), April 2005. [I-D.shin-dstm-ports] Shin, M., "Ports Option Support in DSTM", draft-shin-dstm-ports-00 (work in progress), June 2005. [I-D.yamamoto-v6tc-security-considerations] Yamamoto, S., "Security Considerations for the Tunnel Broker Model", draft-yamamoto-v6tc-security-considerations-00 (work in progress), July 2005. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, February 2000. [RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000. [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. Baker Expires February 13, 2006 [Page 19] Internet-Draft The End to End Problem in Transition August 2005 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004. [RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005. Author's Address Fred Baker Cisco Systems Santa Barbara, California 93117 USA Phone: +1-408-526-4257 Email: fred@cisco.com Baker Expires February 13, 2006 [Page 20] Internet-Draft The End to End Problem in Transition August 2005 Appendix A. Requirements for a general transition strategy What we need is Internet-level transition strategy that defines a limited subset of simple transition mechanisms that provide reliable bi-directional connectivity into a dual-stack backbone and to the global dual-stacked Internet backbone. To avoid the fragmentation this document concerns itself with, the advice of the IPv6 Operations Working Group is that Enterprises should transition to IPv6 by: Case 1: Fully dual stacked backbone: Deploying a native IPv6 service along with native IPv4 service throughout the Enterprise from dual stack hosts to dual stack routers connecting to a dual-stacked Internet backbone. (Preferred method) Case 2: Partially dual-stacked backbone: Deploying a limited number of dual stack "work group" routers with tunnels between them. The dual-stacked work group routers provide both IPv4 and IPv6 service to dual-stack hosts while the majority of the Enterprise backbone network remains IPv4-only. Since the Enterprise has an IPv4- dominant infrastructure throughout most of the Enterprise's backbone, the IPv6-capable work group routers must tunnel IPv6 through the IPv4 enterprise to a central dual-stacked router that connects the IPv6 work group router tunnels and provides service to the dual-stack Internet backbone. Both IPv4 and IPv6 service is provided from the host to the global dual-stacked backbone. It is expected that this network design may be eventually upgraded to case 1. Case 3: Deploying limited IPv6-in-IPv4 tunneling (bidirectional) from dual stack hosts to a tunnel end-point (tunnel broker, 6to4, etc...) that can connect hosts to a native IPv6 backbone. This case assumes an Enterprise architecture with only one (or a few) dual-stacked router which is acting as the IPv6 TEP. This solution has the most overhead and least scalability and should be used for early adoption until upgrades to case 1 or 2 can be made. If the IPv4 infrastructure contains NAT, then the tunnel setup protocol must provide NAT traversal and keep-alive features. All of these provide both native IPv6 and IPv4 connectivity to a fully dual-stacked backbone. That is the key to interoperability. Translation should not be used as an Enterprise solution for IPv6 connectivity - it breaks the End to End model described in [Saltzer], and is too technically complex to maintain as an enterprise service for a large multi-application network. Translation should only be used at the edge of a network for specific pieces of equipment that Baker Expires February 13, 2006 [Page 21] Internet-Draft The End to End Problem in Transition August 2005 cannot be upgraded to IPv6 by a dual-stack software patch. IPv6 dominant networks are only recommended for edge networks that have all internal communications via IPv6 and only a small portion of external communications via IPv4. If the IPv6 dominant network may act as a local backbone that will have to service some IPv4-only networks, then it needs manual (GRE) IPv4-in-IPv6 tunnels or some form of automatic edge-to-edge IPv4-in- IPv6 tunnels (not defined at this point) to service the IPv4 traffic through the infrastructure between IPv4-only islands and to the global dual-stack backbone. Perhaps some form of BGP tunnels could service this need. Baker Expires February 13, 2006 [Page 22] Internet-Draft The End to End Problem in Transition August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Baker Expires February 13, 2006 [Page 23]