Internet DRAFT - draft-baker-v6ops-end2end

draft-baker-v6ops-end2end







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]