[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Internet Engineering Task Force                                P. Savola
Internet Draft                                                 CSC/FUNET
Expiration Date: July 2004
                                                            January 2004


                 A View on IPv6 Transition Architecture

                  draft-savola-v6ops-transarch-03.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

Abstract

   The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is
   a subject of much debate.  However, the big picture of the transition
   doesn't seem to have been discussed sufficiently.  Therefore,
   different people have different assumptions on the process, which
   makes planning the transition architecture very difficult.  This memo
   tries to point out some issues that will need consideration in the
   transition architecture.











Savola                     [Expires July 2004]                  [Page 1]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


Table of Contents

   1.  Introduction  ...............................................   3
   2.  Architectural Considerations  ...............................   3
     2.1.  Fundamental Assumptions about IPv6  .....................   3
     2.2.  General Principles  .....................................   4
     2.3.  Architecting the Transition  ............................   5
     2.4.  Transition Mechanism Deployment Considerations  .........   6
   3.  Transition Mechanism Considerations  ........................   7
     3.1.  Obtaining IPv6 Connectivity  ............................   7
     3.2.  Protocol Translation  ...................................   8
     3.3.  Application Level Gateway or Proxy  .....................   8
   4.  Node Deployment Model Considerations  .......................   9
     4.1.  IPv4-only  ..............................................   9
     4.2.  Dual-stack with Only IPv4 Connectivity  .................  10
     4.3.  Dual-stack w/ IPv4/6 Connectivity  ......................  10
     4.4.  Dual-stack with Only IPv6 Connectivity  .................  11
     4.5.  IPv6-only  ..............................................  11
   5.  Service Deployment Model Considerations  ....................  12
     5.1.  IPv4-only  ..............................................  12
     5.2.  Separate IPv4 and IPv6  .................................  12
     5.3.  IPv4/6  .................................................  13
     5.4.  IPv6-only  ..............................................  14
   6.  Implications of the Transition Architecture Considerations  .  14
   7.  A View on Transition  .......................................  15
     7.1.  The Cost of Dual-stack Compared to IPv6-only  ...........  15
     7.2.  Generic Protocol Translation in IPv6  ...................  16
     7.3.  Providing IPv6-enabled Services -- How?  ................  17
   8.  Acknowledgements  ...........................................  18
   9.  Security Considerations  ....................................  18
   10.  References  ................................................  18
     10.1.  Normative  .............................................  18
     10.2.  Informative  ...........................................  19
   Author's Address  ...............................................  19
   A.  Example Mechanism: TCP/UDP Relay  ...........................  19
   Intellectual Property Statement  ................................  20
   Full Copyright Statement  .......................................  20














Savola                     [Expires July 2004]                  [Page 2]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


1. Introduction

   The transition from IPv4 to IPv6 and co-existence of IPv4 and IPv6 is
   a subject of much debate.  However, the big picture of the transition
   doesn't seem to have been discussed sufficiently.  Therefore,
   different people have different assumptions on the process, which
   makes planning the transition architecture very difficult.

   This memo points out some issues that will need consideration in the
   transition architecture, as well as point out a few views on certain
   transition approaches.

   As a semantic note, the phrase "IPv6 Transition" is used to refer to
   the process of enabling the use of IPv6.  In practice, the means
   IPv4/IPv6 dual-stack co-existence.  The term "transition" comes from
   transitioning from IPv4-only networks to networks where IPv6 has been
   enabled; it is not meant to imply IPv6 networks where IPv4 has been
   disabled.

   In section 2, the important architectural transition considerations
   are introduced.  In section 3, 4, and 5, the transition mechanism,
   node deployment and service deployment considerations, respectively,
   are discussed at more length.  In section 6, the implications of the
   transition architecture are summarized.  In section 7, several
   personal views on the IPv6 transition are described.

2. Architectural Considerations

   This section lists some fundamental architectural considerations to
   keep in mind in the transition process; most of these will be
   discussed at more length later.

2.1. Fundamental Assumptions about IPv6

   People have different assumptions what the transition to IPv6 and co-
   existence with IPv6 means.  This makes it more difficult communicate
   and gain consensus on how IPv6 should evolve and be deployed. For
   example [PREMISES] lists a number of questionable assumptions, like:

     o at some point, IPv4 will become obsolete because of wide-spread
       IPv6 adoption,

     o IPv6 will not be adopted unless it provides the same solutions to
       the perceived problems as IPv4 does (e.g. a form of local
       addressing, NATs), or






Savola                     [Expires July 2004]                  [Page 3]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


     o dual-stack IPv6 + natted-IPv4 is not an interesting replacement
       for an already-natted IPv4 host.

   This memo does not try to present or assume definitive answers to
   these dubious premises.  However, the author of this document mostly
   agrees with [PREMISES] in that IPv6 is better served as an enabler of
   a different model of networking than as an immediate replacement for
   IPv4.

   It is very important that the reader gives these assumptions a lot of
   thought, as the approach to the IPv6 transition/co-existence will be
   entirely different, given different assumptions.  This is probably
   the most important single point of confusion or miscommunication
   between different people working on IP technologies.

2.2. General Principles

   General principles which should be carefully considered when
   architecting the transition include at least:

     o security

     o simplicity

     o robustness

   Actually, all of these are somewhat related; similar considerations
   have also been noted in the Internet architectural principles [ARCH].

   Security is very important: the transition architecture in general,
   or the transition mechanisms in particular, must not enable
   significant security threats, as that might cause the holes to be
   abused and make people hesitant to start the transition.

   Simplicity is crucial: this includes the overall simplicity of the
   transition architecture (for example, a limited set of mechanisms or
   operational practices which have clear uses and different clearly
   defined problems -- not too many tools to make the choices between
   them too difficult), and the simplicity of the transition mechanisms
   themselves.  Simple systems have the tendency to work well even under
   unexpected circumstances, and are less prone to security, robustness,
   and other problems.  If more complex systems have to be built,
   they're better done using a set of simple building blocks.

   Robustness is also essential: the mechanism and the architecture must
   be reliable and robust, to encourage the adoption.  The IPv6 and the
   dual IPv4/6 architecture must not be less robust than the IPv4-only
   architecture.  For example, there are some IPv4 components (like



Savola                     [Expires July 2004]                  [Page 4]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   NATs, or worse, depending on some specific features on how NATs
   operate) that are not always reliable.  The success of IPv4/6 must
   not be dependent on how these mechanisms (mis)operate, as creating
   such a dependency could easily transfer these problems of IPv4 to
   IPv6 -- and would negatively impacting the reliability and usefulness
   of IPv6 as a whole.

2.3. Architecting the Transition

   A plan how the IPv6 transition is to be done is needed.  However, the
   crystal balls are always a bit cloudy: it is difficult to predict how
   the transition will progress.  Therefore, when in doubt how to
   proceed, one should choose an action that is least likely to hurt the
   transition process in the future.

   That is, it is important to move forward with the IPv6 transition,
   even if by taking small steps.  For example, deploying dual-stack
   nodes or applications, even without IPv6 connectivity is an enormous
   and critical step in the process, as that will enable the easier
   adoption of IPv6 later on.  Both of these steps will be necessary
   anyway, so we've identified at least two "safe" actions: work done on
   them is well spent. Such "safe" actions move the transition to the
   right direction even though we may not have the yet gained a full
   vision of the complete transition architecture.

   When defining the architecture, there are typically different
   building blocks to be used, from different classes as described
   below.

   "Mechanisms" are the building blocks to be used for to provide IPv6
   connectivity, or to interoperate betweek IPv4 and IPv6.  They are
   further described in section 3; these are:

      1. Providing IPv6 connectivity
      2. Protocol translation
      3. Application-specific protocol interoperability (i.e., ALG or
         proxy)

   "Deployment models for nodes" are the ways how IP nodes might be
   deployed, including the different combinations of IPv4/6 capabilities
   and connectivity.  They are further described in section 3; these
   are:

      1. IPv4-only
      2. Dual-stack with only IPv4 connectivity






Savola                     [Expires July 2004]                  [Page 5]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


      3. Dual-stack w/ IPv4/6 connectivity
      4. Dual-stack with only IPv6 connectivity
      5. IPv6-only

   "Deployment models for services" are the ways how IP services
   ("applications") could be provisioned; this may be slightly different
   from the node IP deployment model.  They are further described in
   section 4; these are:

      1. IPv4-only
      2. Separate IPv4 and IPv6
      3. Both IPv4/6
      4. IPv6-only

   After discussing these in sections 3-5, conclusions are presented in
   section 6.  The subsection below provides a few considerations to
   bear in mind when considering the details of different mechanisms or
   deployment models.

2.4. Transition Mechanism Deployment Considerations

   There are a few very important questions which must be addressed in
   the cases where a transition mechanism deployment is deemed
   necessary.  For example:

     o if I have an existing IPv4-only service (e.g., a web site) or if
       I deploy IPv4-only service, whose burden is it to enable its use
       by all clients I wish to make it accessible to?

     o if I deploy IPv6-only service (e.g., a peer-to-peer application,
       or a special web site), whose burden is it to enable its use by
       all clients I wish to make it accessible to?

     o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6
       connectivity, whose burden is it to enable them to access all the
       services they want?

     o how much easier would it be to go for dual-stack approach
       instead?

   These are complex questions.  One could examine this at least from an
   architectural point-of-view in addition to considering where the
   momentum of each approach lies.

   That is, it would be desirable to architecturally try to ensure that
   everybody is responsible to achieving the greatest amount of
   interoperability while retaining the reasonable tradeoff of the
   general principles (security, simplicity, and robustness).



Savola                     [Expires July 2004]                  [Page 6]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   On the other hand, one should realize the momentum of each scenario:
   until the IPv6 usage levels are really significant globally (for
   example, nearing 50%), it could be considered that that the new
   deployments have a primary responsibility for ensuring this
   interoperability.

   So, it is not wise to assume IPv6 will gain enough momentum in the
   short/medium term that you would not have to take care of being able
   to reach the existing IPv4 services yourself, either using IPv4 or
   IPv6.  It is not reasonable to expect all the services to be
   IPv6-enabled. On the other hand, it would be perfectly fine to get
   someone else (e.g. a service provider providing extra IPv6 services)
   to do it for you.

   Of course, when considering an option like this, one should always be
   very careful not to forget comparing the situation to the cost of
   deploying a dual-stack solution.  Typically, a dual-stack solution is
   much easier to cope with than the alternative, and the total cost is
   less.

3. Transition Mechanism Considerations

   Now, the considerations associated with the basic transition building
   blocks are discussed in more detail; these are:

      1. Providing IPv6 connectivity
      2. Protocol translation
      3. Application-specific protocol interoperability (i.e. ALG or
         proxy)

3.1. Obtaining IPv6 Connectivity

   Obtaining IPv6 connectivity is an important step when moving from the
   deployed base of dual-stack nodes to the use of IPv6-enabled
   services.  These do *not* have to happen simultaneously: indeed, it
   can even be counter-productive to enable IPv6 connectivity
   immediately (more of this below).

   The connectivity methods could be classified in several ways, but
   here is one:

     o native
     o tunneled over IPvX to a close tunnel end-point
     o tunneled over IPvX (over longer distances)

   The tunneled connectivity mechanisms could also be considered to
   include subcategories "configured" and "automatic".  A "configured
   tunnel" implies that the tunnel endpoint -- especially for received



Savola                     [Expires July 2004]                  [Page 7]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   packets -- is known in advance, and is somewhat trusted.  An
   "automatic tunnel" implies a mechanism where the tunnel endpoints are
   not known and there is a smaller degree of trust -- if any!

   Otherwise, these should be self-evident.  When considering the
   robustness and simplicity principles, the first two seem to be
   superior to more global connectivity mechanisms: when an underlying
   network topology of a tunnel includes multiple different
   administrative or technical entities, the probability of failures
   increases tremendously.  Similarly, the automatic mechanisms are
   significantly more worrisome than configured ones, especially when
   applied in a domain as large as the whole Internet.

   As stated above, "premature" IPv6 connectivity could be knotty
   problem because the operating systems try IPv6 by default if no
   protocol has been specified explicitly.  Therefore, when IPv6
   connectivity is enabled (or, to a lesser degree, even IPv6 is enabled
   -- more of this in section 4), it becomes critical to ensure that the
   IPv6 connectivity is of equal qualityas IPv4 or that IPv6 is only
   used by specific applications, for specific purposes.

   That is, low-quality IPv6 connectivity could result in a visible
   service degradation to the user, which would delay the moment when
   the users feel comfortable with switching on IPv6 without too many
   side-effects.  These issues have been discussed at length in
   [6BMESS].

3.2. Protocol Translation

   Protocol translation is used to refer to mechanisms which perform a
   NAT-PT or SIIT -like automatic translation of all the packets,
   regardless of content, or (typically) application compatibility.

   These may work to some level of success for limited deployment
   scenarios and sets of applications only, but do not seem to fulfill
   robustness and simplicity principles in general.

   A view on the problems of generic translation is presented in section
   7.2.

3.3. Application Level Gateway or Proxy

   It is well known that a protocol translator must have an ALG with it,
   to deal with protocols (as simple as FTP) that contain direct
   dependencies on IP addresses. However, ALGs may exist in the absence
   of a protocol translator, and in this case they are better described
   as proxies.




Savola                     [Expires July 2004]                  [Page 8]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   If all protocols of interest (e.g. SMTP, HTTP, SIP,...) are handled
   by a proxy at the boundary between IPv4 and IPv6, no IP level
   translation is needed.

   A typical disadvantage of proxies is that their use must be
   explicitly configured in the applications unless automated somehow.

   The advantage of proxies -- or in general, mechanisms which have been
   explicitly configured, on a service-by-service basis -- over generic
   protocol translators is that their interface to the existing
   infrastructure is well defined.  If configured to act to proxy just
   one service, it can be assumed that the proxy is restricted to that
   service only, and understands the application details.

   That is, proxies do not break applications that e.g. pass the IP
   addresses in the payloads as by definition, the proxy acts as an
   explicit endpoint in the communication.

4. Node Deployment Model Considerations

   There are multiple ways how to deploy IP versions in the nodes, and
   how to provide the connectivity to these IP versions.  These are
   discussed at more length here. Deployment models for IP nodes are:

      1. IPv4-only
      2. Dual-stack with only IPv4 connectivity
      3. Dual-stack w/ IPv4/6 connectivity
      4. Dual-stack with only IPv6 connectivity
      5. IPv6-only

4.1. IPv4-only

   This is an obvious model how nodes have been deployed in the past,
   and will also continued, to some extent, be deployed in the future.

   There are obviously two cases to consider here:

     o IPv6 has not been implemented in the system being deployed at
       all, or

     o IPv6 has been implemented in the system (to some degree), but it
       is not enabled in the kernel, library functions, etc.

   The first is obvious: IPv6 just isn't there, so nothing can be done
   about it, except maybe try to request the support to be included in
   the future revisions, or to pick a different kind of system.





Savola                     [Expires July 2004]                  [Page 9]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   The second is a bit more subtle: either the vendor or the user has
   decided that enabling IPv6 (whether explicitly, or by default) does
   not make sense yet.  This is understandable in the face of issues
   which may result from doing that [ONBYDEF].  It is expected that when
   sufficient experience has been gained from enabling IPv6 by default,
   it will become more commonplace.  However, even deploying IPv4-only
   nodes which implement IPv6 is a step to the right direction.

4.2. Dual-stack with Only IPv4 Connectivity

   This is an extension of the second case above: IPv6 dual-stack has
   been deployed and enabled, but for some reason, there is only IPv4
   connectivity.

   Having only IPv4 connectivity, or only very limited IPv6
   connectivity, may be intentional; if there are concerns about the
   robustness of IPv6, some may consider it appropriate to wait prior to
   starting to prefer IPv6 over IPv4 by not providing global IPv6
   connectivity yet, as discussed in section 3.1.

   Having dual-stack enabled but with only IPv4 connectivity implies
   that the IPv6 loopback address is automatically configured, and each
   interface has an IPv6 link-local address, and that all the IPv6
   destinations are considered to be on-link.  This is highly
   problematic in most cases [ONLINK], as well because the getaddrinfo
   AI_ADDRCONFIG flag will start returning IPv6 addresses when a link-
   local address has been configured [RFC3493].  There are likely many
   other issues like these, but these will be overcome and fixed as more
   experience is gained from the deployment.

4.3. Dual-stack w/ IPv4/6 Connectivity

   The next logical model is obviously deploying dual-stack nodes with
   full IPv4/6 connectivity.  This is the phase which is expected to
   become dominant in the new deployments in the short/middle term, and
   continue to increase gradually for a long time as IPv4 and IPv6 co-
   exist in the Internet.

   In this phase, it is critically important that the applications have
   been developed properly; for example, [APPTRANS] gives some
   guidelines on that.  In particular, they must be able to gracefully
   fall back when IPv6 connectivity does not work to IPv4, or vice versa
   (depending on which protocol is preferred).

   As this phase is expected to take the longest amount of time, it is
   imperative to ensure that the scenario does not have any flaws.





Savola                     [Expires July 2004]                 [Page 10]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


4.4. Dual-stack with Only IPv6 Connectivity

   Another deployment model is deploying just IPv6 connectivity on dual-
   stack nodes.

   One scenario where this could be applicable in the mid-long term
   could be some special-purpose nodes or applications, which are known
   before the fact that they will only need to communicate with IPv6
   nodes and applications.  These are very like very few in the
   short/middle term, as the deployment base of IPv6 needs to be grown
   first.

   This model is obviously better than "IPv6-only" because it is still
   possible to go back to dual-stack, just by enabling IPv4
   connectivity.

   Except for the very specific scenarios identified above, this
   scenario does not seem to be relevant in a very, very long time.

4.5. IPv6-only

   IPv6-only is the final deployment model.  Either the IPv4 stack has
   been removed, or it has been disabled completely.

   IPv6-only deployments would imply that the nodes and applications
   would never want to communicate with IPv4 nodes, or would do so
   through a proxy or protocol translator.

   Because the period of dual-stack infrastructure is expected to last
   for a very, very long time, it does not make sense to deploy
   IPv6-only infrastructures until about all the relevant IPv4 services
   and nodes have been retired.  If generic protocol translation would
   be needed, this would seem like a clear indication that the
   transition has not progressed as far as it should have been prior to
   switching to IPv6-only.  These issues have been discussed at more
   length in section 7.

   Therefore, it is completely premature to consider IPv6-only
   deployments as of writing this memo.












Savola                     [Expires July 2004]                 [Page 11]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


5. Service Deployment Model Considerations

   Similarly, there are multiple ways to deploy services. Here, we use
   the term "service" to describe an application deployed by the
   facilitator of the service (XXX: if you can think of more unambiguous
   term to use, please send suggestions!). These are discussed at more
   length here.  The models are:

      1. IPv4-only
      2. Separate IPv4 and IPv6
      3. IPv4/6
      4. IPv6-only

   We examine services from the "server's" (or in more general, the
   facilitator of the service) perspective.  How the support for using
   services is deployed is assumed to, in most cases, be decided by the
   node deployment model (section 4).

5.1. IPv4-only

   Obviously, IPv4-only services is the initial deployment model.  Most
   current deployments are IPv4-only, but are slowly changing to also
   enable IPv6 services.

   This is the safest deployment in the sense that its problems are well
   known, and there is ample experience of such IPv4-only deployments.
   Unfortunately, doing so will not progress the IPv6 transition
   process, and the dual-stack, IPv4/6-connected nodes will have to
   reach these services over IPv4.

   However, the deployment of IPv4-only services is not necessarily a
   bad thing: one should not expect that all the services become
   IPv6-enabled for a very long time.  It could be argued that the
   services will be IPv6 enabled when it makes sense for the service
   provider to do it.  This could be due to a specific application that
   profits from features of IPv6, as a general dual-stack service
   policy, etc.

5.2. Separate IPv4 and IPv6

   Here, the term "Separate IPv4 and IPv6" is used to refer to services
   that are not reachable the same way; for example, this could be the
   service on the same (or different) host being available on
   www.example.com and www.ipv6.example.com, a service provider
   providing IPv6 SMTP mail exchange (MX) service for IPv4-only sites,
   or the like; note that "separate" could be considered to include an
   application level gateway of a sort.




Savola                     [Expires July 2004]                 [Page 12]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   One issue of separate IPv4 and IPv6 services is that they do not have
   similar "fate-sharing" properties.  One service could be down while
   the other remains up.  This is typically a negative thing, when IPv6
   services are used less frequently than their IPv4 counterparts; IPv6
   services could be down or not functioning properly (without timely
   reaction from the administrators) while IPv4 works fine.

   To summarize, one should be wary when deploying especially some forms
   of separate services; a factor here is the stage of the transition.
   They are often more difficult to manage and troubleshoot, and there
   is the problem of service getting out-of-sync.

   A mechanism which has been used to facilitate separate services is
   described briefly in Appendix A.

5.3. IPv4/6

   The obvious long-term deployment model for certain services at least
   is IPv4/6, that is, the same application provides the support for
   both protocol versions.

   There are a number of pitfalls here relating how the applications are
   developed [APPTRANS], but it should be expected that one will be able
   to overcome and fix these issues to enable robust use of application
   in every case.

   IPv4/6 service deployment (at least for those applications which are
   relevant for IPv4) is the best approach in the long run.  The rate
   and the timing of service deployment depends on many factors, e.g.,
   the extent of IPv6 deployment in the user base, and how aggressive
   IPv6 deployment plan has been adopted for the service.

   However, it should be noted that in the early stages of the
   transition, this might lead to some bad effects to the users -- this
   places some requirements on the quality and availability of IPv6
   connectivity on all or most of the users of the service, as is
   pointed out in section 3.1.

   There certainly are many issues left to be worked out; these will not
   be fixed unless the services will be actually used.  At a critical
   point, the "burden" of fixing problems caused by IPv6 service
   deployment shifts to those who have not deployed it (properly) yet.
   It is important to get to that point.  This point is brough closer by
   those who are in the "cutting edge", providing services despite
   potential problems, paving the way for the mainstream deployment
   phase.





Savola                     [Expires July 2004]                 [Page 13]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


5.4. IPv6-only

   The last deployment model for services is IPv6-only.  Obviously, it
   is not suited for all the services in a very, very long time.

   However, there are some uses for this model with some specific
   applications.  Some applications may be able to assume that they will
   only be run over IPv6, for whatever reason (e.g., simplicity of not
   having to implement NAT workarounds).  This kind of approach might
   make perfect sense in some specific scenarios where one can assume
   that the users of the service are all able to use IPv6.  On the other
   hand, providing an IPv6-only service when all its users would not
   have IPv6 capabilities would not be appropriate.

6. Implications of the Transition Architecture Considerations

   Having described the different deployment model considerations, the
   implications need to be considered.

   Let's consider the deployment models for nodes and services, trying
   to optimize for the scenario where the need for the mechanisms would
   be minimized; that is:

        +---------+---------+--------+------+---------+
        |Node\Srvc|IPv4-only|Separate|IPv4/6|IPv6-only|
        +---------+---------+--------+------+---------+
        |IPv4-only|   +++   |   +++  |  +++ |   2,3   |
        +---------+---------+--------+------+---------+
        |DS w/IPv4|   +++   |   +++  |  +++ |  1?,2,3 |
        +---------+---------+--------+------+---------+
        |DS w/both|   +++   |   +++  |  +++ |   +++   |
        +---------+---------+--------+------+---------+
        |DS w/IPv6| 1?,2,3  |   +++  |  +++ |   +++   |
        +---------+---------+--------+------+---------+
        |IPv6-only|   2,3   |   +++  |  +++ |   +++   |
        +---------+---------+--------+------+---------+

   The matrix is intuitive; all off-the-shelf working combinations are
   listed with "+++".  In the remaining four instances, the possible
   transition mechanisms that could be applied are listed.

   So, the easiest thing to do would be to ensure that the service or
   deployment model matches one of these categories.  However, some of
   these are suboptimal, as they do not progress the transition (for
   example, IPv4-only nodes and services).

   To summarize, it would be desirable if the services would not be
   deployed IPv4-only or IPv6-only, and the nodes dual-stack with both



Savola                     [Expires July 2004]                 [Page 14]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   IPv4/6 connectivity.

   This is the goal we should be working toward.  However, the goal can
   be achieved using a big step, or a set of smaller steps.

   As already described, these issues can also be viewed a bit more
   pragmatically: the deployment base of IPv4 is so huge that assuming
   mainstream IPv6 adoption in the short term is not necessarily
   feasible.  Therefore, deploying dual-stack nodes but without IPv6
   connectivity is still a step in the right direction, and keeping the
   services IPv4-only is not necessarily a huge problem.

   That is, for example, early adopters give experience back to the
   community which allows for smoother and more problem-free
   introduction of IPv6 to the masses later on.  Advocating strongly
   that IPv6 should be deployed everywhere quickly might backfire and
   turn out to be counter-productive -- as there are likely some issues
   to be identified and worked out prior to the co-existence could be
   deemed to be a trivial exercise.

7. A View on Transition

   This section includes a few views on several aspects of the
   transition.

7.1. The Cost of Dual-stack Compared to IPv6-only

   An oft-cited argument against deploying dual-stack instead of
   IPv6-only with some generic translation and proxying is that the
   management of a dual-stack networks, address assignments etc. is a
   significant burden and should be avoided.

   In practice, this seems highly questionable.  Naturally, the overall
   complexity one should compare the dual-stack architecture against is
   the IPv6-only architecture AND everything that's required to make it
   work with a mostly-IPv4 universe.

   For example, there is a routing protocol which allows a single
   Shortest Path First (SPF) calculation for both IP protocols -- the
   increase of management complexity seems close to negligible.

   Even address assignments are quite straightforward.  IPv6 has to be
   done anyway; IPv4, if private addresses would be used, would be
   straightforward, but the issues relating to IPv6-only networks and
   protocol translation would result in about equal problems with
   translated-IPv4 than with private IPv4 addresses. On the other hand,
   if public IPv4 addresses are obtainable and desirable, the management
   of those is a task, although not a major one.  So, it seems that the



Savola                     [Expires July 2004]                 [Page 15]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   only addressing related concern seems to be being able to avoid the
   paperwork with Regional Internet Registries (RIRs) relating to public
   IPv4 addresses.

   The desire to go straight to IPv6-only seems to be mainly caused by a
   dream of fast transition to IPv6-only especially in some more evolved
   networks.  However, this seems counter-productive.  (Of course, a
   fast transition to a state where IPv6 applications are being
   extensively used and IPv6 is becoming more and more dominant is a
   separate subject.)

   There is a class of dedicated devices and applications for which
   IPv6-only may be warranted -- these are those that, for whatever
   reason, are only to be deployed in IPv6-capable networks, and only
   need to inter-operate with IPv6 nodes.  Generic translation is not
   necessary, and at most some form of simple application proxying is
   used.  When/if these emerge, they could be deployed in an IPv6-only
   fashion .. but still, the network would be dual-stack.

   It might be that this stanza could change significantly in (say) 10
   years if the deployment gets off, but prior to major global
   deployment happens (e.g., causing over 3/4 of services be available
   over IPv6), any action toward generic IPv6-only networks, as a
   generic replacement to IPv4 networks, seems premature.

7.2. Generic Protocol Translation in IPv6

   One argument for generic protocol translation (referring to
   translation done not just on a specific set of applications) in
   IPv6-only networks (see above) is that protocol translation is not
   that much different from NAT and the users would, in many cases, be
   plagued by that too.

   This is pretty close to the mark, for better and _worse_.

   In particular, generic protocol translation eliminates the ideal that
   applications are not munged by NATs in IPv6.  A reason to deploy an
   IPv6 application could be to be able to get rid of the problems of
   NATs in the first place.

   Thus, not polluting IPv6 with protocol translation seems to be
   desirable goal on its own.  In this light, it is more desirable to
   just continue using IPv4 when needed, and keeping IPv6 as "high
   quality".

   That is, an IPv6 application could end up used to connect to IPv4
   peers though a translator, when the "promise of IPv6" (which may have
   been included in the design of the application) was that no



Savola                     [Expires July 2004]                 [Page 16]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   translation would be performed with IPv6.

   This could be summarized so that we (the IPv6 deployers) cannot
   change what IPv4 is: the applications and users already have certain
   expectations of it and they deal (or don't) with them.  However, we
   can still ensure that IPv6 will not be riddled with IPv4's problems,
   whether in the coexistence with IPv4 (important) or in the
   communication between IPv6 nodes themselves (critical).

   Encouraging generic protocol translation only seems to support the
   wrong kind of IPv6 deployment (see above), and carrying the problems
   of IPv4 NAT to IPv6.  This seems counter-productive.

7.3. Providing IPv6-enabled Services -- How?

   Providing IPv6-enabled services is an extremely tricky business which
   has a number of caveats which should be taken into serious
   consideration.

   First, we'll assume that in the first phase, it is crucial to improve
   the number of dual-stack (even without IPv6 connectivity) nodes.
   This seems a reasonably safe assumption.

   Now, a potential problem appears when someone wishes to provide also
   IPv6-enabled service alongside with their IPv4 service: the first
   priority, for all parties -- the service provider, the vendor of the
   dual-stack nodes and the users -- is that enabling IPv6 will not
   degrade the perceived performance of existing applications.
   Otherwise, only few would be willing to deploy dual-stack nodes (or
   connectivity), or enable IPv6 on their services. This also seems to
   be a reasonable assumption on the goal to be work toward.

   A temporary workaround would be to deploy the IPv6 services under
   different service identifiers, like www.ipv6.example.com rather than
   www.example.com.  In general, this is a relatively safe mechanism,
   but only carries so far: the potential IPv6 users will still use
   www.example.com because they are not aware of the sub-domain.

   A fix for this would be changing the default address ordering to
   prefer A DNS records over AAAA records: then, IPv6 addresses could be
   added for standard names without worries, and the nodes themselves --
   not the one implementing service -- would be capable of making a
   decision when to switch the toggle the other way around.

   The change in the default ordering should already be doable with a
   custom Default Address Selection rule [ADDRSEL], but unless the
   existence or deployment of such a rule would be commonplace, this
   methodology would not work.  So, it may be that the "deployment



Savola                     [Expires July 2004]                 [Page 17]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   window" for this approach has already passed.

   The requirement for this problem to go away is globally stable and
   robust IPv6 connectivity.  It seems to take long until that is
   achieved [6BMESS]; this was also briefly discussed ini section 3.1.
   for some IPv4-enabled services to the IPv6 users.

8. Acknowledgements

   Discussions with Brian Carpenter gave a push to writing this memo.
   Discussions with Rob Austein, Suresh Satapati, and Juha Wiljakka
   inspired into revising the memo.  Suresh Satapati, Jim Bound, and
   Michael Mackay provided feedback, helping in improving the document.
   Keith Moore's "dubious premises" email helped a lot to spell out
   which kind of fundamental differences of assumptions people have
   about IPv6.

9. Security Considerations

   Transition architecture discussion has no special security
   considerations as such; however, one must be very careful not to
   introduce an new security considerations when specifying and
   deploying the transition architecture.

   In the quick analysis above, mainly only the robustness and
   simplicity principles were considered, leaving security to follow
   from these.  A more careful security review will be needed in the
   future.

10. References

10.1. Normative

   [ARCH]      Bush, R., Meyer, D., "Some Internet Architectural
               Guidelines and Philosophy", RFC3439, December 2002.

   [PREMISES]  Moore, K., "dubious premises: batch reply to "IPv6
               adoption behaviour"", a message on ipv6@ietf.org list on
               21 Oct 2003, http://www1.ietf.org/mail-archive/
               working-groups/ipv6/current/msg00398.html or
               http://www.cs.utk.edu/~moore/opinions/ipv6/
               dubious-assumptions.html









Savola                     [Expires July 2004]                 [Page 18]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


10.2. Informative

   [6BMESS]    Savola, P., "Moving from 6bone to IPv6 Internet",
               draft-savola-v6ops-6bone-mess-01.txt, work-in-progress,
               November 2002.

   [ADDRSEL]   Draves, R., "Default Address Selection for IPv6",
               RFC 3484, February 2003.

   [APPTRANS]  Shin, M., "Application Aspects of IPv6 Transition",
               draft-ietf-v6ops-application-transition-00.txt,
               work-in-progress, December 2003.

   [ONBYDEF]   Roy, S., et al., "Dual Stack IPv6 on by Default",
               draft-ietf-v6ops-v6onbydefault-00.txt, work-in-progress,
               October 2003.

   [ONLINK]    Roy, S., et al., "IPv6 Neighbor Discovery On-Link
               Assumption Considered Harmful", draft-ietf-v6ops-
               onlinkassumption-00.txt, work-in-progress, October 2003.

   [RFC3493]   Gilligan, R., et al., "Basic Socket Interface
               Extensions for IPv6", RFC 3493, February 2003.

   [RELAY]     Hagino, J., Yamamoto, K., "An IPv6-to-IPv4 Transport
               Relay Translator", RFC3142, June 2001.

Author's Address

   Pekka Savola
   CSC/FUNET
   Espoo, Finland
   EMail: psavola@funet.fi

A. Example Mechanism: TCP/UDP Relay

   This appendix describes the use of one mechanism for controlled help
   in IPv6 adoption, using the "separate IPv4 and IPv6" service model.

   [RELAY] provides a mechanism to perform protocol interoperability on
   a service-by-service basis which has decoupled interactions with DNS
   from the service management.

   TCP/UDP relay can be deployed at two different locations: on the
   client side or the server side.  On the client side, the usability
   appears to be a bit questionable, bringing up many issues regarding
   the interaction between the DNS and service proxying.  However, on
   the server side, it is much simpler.



Savola                     [Expires July 2004]                 [Page 19]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   That is, for example, a gateway between IPv4-only NNTP service and a
   dual-stack relay at the NNTP service providers' network can be easily
   and relatively reliably built with a TCP relay.  This includes
   publishing the address of the TCP relay pointing toward the NNTP
   server in the DNS, configuring sufficient access-lists so that only
   the NNTP service is reachable, and configuring access-lists that only
   valid users have the access to use the relay service.  The latter is
   necessary because the IPv4-only service sees the connections
   originating from the relay (and the real IPv6 source is lost); this
   is unfortunate, but unavoidable.

   Of course, in most cases, deploying IPv6-enabled services from the
   start is the best, and simplest choice.  However, the TCP/UDP relay
   seems to be sufficiently simple and robust mechanism when used for
   providing a gateway

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this



Savola                     [Expires July 2004]                 [Page 20]


Internet Draft     draft-savola-v6ops-transarch-03.txt      January 2004


   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.





























Savola                     [Expires July 2004]                 [Page 21]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/