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]