Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET
Expiration Date: August 2003
February 2003
A View on IPv6 Transition Architecture
draft-savola-v6ops-transarch-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is
a subject of much debate. However, the big picture of the transition
seems not to have been discussed sufficiently. Therefore, different
people have different assumptions on the process, which makes
planning the transition architecture very difficult: indeed, it seems
that there is a lack of architecture in the transition process. This
memo tries to point out some issues that will need consideration in
the transition architecture, as well as point out a few personal
views on certain transition approaches.
Savola [Expires August 2003] [Page 1]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
Table of Contents
1. Introduction ............................................... 2
2. Architectural Considerations ............................... 3
2.1. General Principles ..................................... 3
2.2. Architecting the Transition ............................ 3
2.2.1. Mechanisms, Deployment Models, and Services ........ 4
2.2.2. Implications ....................................... 4
2.3. Transition Mechanism Deployment Considerations ......... 5
3. Transition Mechanism Considerations ........................ 6
3.1. Obtaining Connectivity ................................. 6
3.2. Protocol Translation ................................... 7
3.3. Application Level Gateway .............................. 7
3.4. Application Proxy ...................................... 7
4. A View on Transition ....................................... 7
4.1. Providing IPv6-enabled Services ........................ 8
4.2. Deployment of IPv6-only Nodes .......................... 8
4.3. Deploying IPv6-only Sites .............................. 9
4.4. The Role of an IPv6 ISP ................................ 9
4.5. Example: DSTM .......................................... 10
4.6. Example: TCP/UDP Relay ................................. 10
5. Acknowledgements ........................................... 11
6. Security Considerations .................................... 11
7. References ................................................. 11
7.1. Informative ............................................ 11
Author's Address ............................................... 11
1. Introduction
The transition from IPv4 to IPv6 and co-existance of IPv4 and IPv6 is
a subject of much debate. However, the big picture of the transition
seems not to have been discussed sufficiently. Therefore, different
people have different assumptions on the process, which makes
planning the transition architecture very difficult: indeed, it seems
that there is a lack of architecture in the transition process.
This memo tries to point out some issues that will need consideration
in the transition architecture, as well as point out a few personal
views on certain transition approaches.
As a semantic note, "IPv6 Transition" here is used to refer to the
process of enabling the use of IPv6. In practise, the first stage is
mostly IPv4/IPv6 dual-stack co-existence. The term "transition"
comes from transitioning from IPv4-only networks to networks wehre
IPv6 has been enabled.
Savola [Expires August 2003] [Page 2]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
2. Architectural Considerations
2.1. General Principles
General principles which should be carefully considered when
architecturing the transition include at least:
o security
o simplicity
o robustness
Actually, all of these are somewhat related; similar has also been
noted in the Internet architectural principles [ARCH].
Security is very important: deploying transition mechanisms must not
enable significant security holes, as that might cause the holes to
be abused and make people hesitant to start the transition.
Simplicity is crucial: this includes the overall simplicity of the
transition architecture (for example, a limited set of mechanisms or
operational practises which have clear uses -- not too many tools to
make the choices between them too difficult), and the simplicity of
the transition mechanisms themselves. Simple systems have the
tendency to work well even under unexpected circumstances, and are
less prone to security, robustness, and other problems. If more
complex systems have to be built, they're better done using a set of
simple building blocks.
Robustness is also essential: the mechanism and the architecture must
be reliable and robust, to encourage the adoption. Also, mechanisms
must not be less robust than their IPv4 counterparts: quite the
contrary. It is highly desirable to aim for building the
architecture which does not depend on known-unreliable components
(for example, certain operational modes of IPv4 NAT's); otherwise,
the whole architecture is easily deemed unreliable.
2.2. Architecting the Transition
There has to be some form of plan how the IPv6 transition is to be
done.
In absence of a plan, the transition must be made so that the future
transition options will not be end-ran, and only "safe" transitionary
actions are executed. For example, deploying dual-stack nodes with
currently only IPv4 connectivity does not end-run any transitionary
goals, but is an important step that must be done anyway.
Savola [Expires August 2003] [Page 3]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
2.2.1. Mechanisms, Deployment Models, and Services
When forming a transition architecture, there are typically different
building blocks to be used, from different classes, including:
Mechanisms:
o Providing IPv6 connectivity
o Protocol translation
o Application-specific protocol interoperability (ie. ALG or proxy)
Deployment models for IP nodes:
o IPv4-only
o Dual-stack with only IPv4 connectivity
o Dual-stack w/ IPv4/6 connectivity
o Dual-stack with only IPv6 connectivity
o IPv6-only
And services:
o IPv4-only
o Separate IPv4 and IPv6
o IPv4/6
o IPv6-only
In above, "Separate" is used to refer to services that are not
reachable the same way; for example, this could be the service on the
same (or different) host being available on www.example.com and
www.ipv6.example.com, a service provider providing IPv4 SMTP mail
exchange (MX) service for IPv6-only sites, or the like; note that
"separate" could be considered to include an application level
gateway of a sort.
One should be wary when deploying "Separate" or "IPv4/6" services.
Both have their advantages and disadvantages, which depend heavily on
the stage of the transition. Namely, some forms of separate services
are often more difficult to manage and troubleshoot, and there is the
problem of service getting out-of-sync; on the other hand, deploying
IPv4/6 services before IPv6 connectivity is stable enough has it's
own severe disadvantages, as will be pointed out in the following
sections.
2.2.2. Implications
From the three categories listed above, one can note that you will
only need to go to the first, mechanisms, category if the last two do
not give satisfying combinations. That is:
Savola [Expires August 2003] [Page 4]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
+---------+---------+--------+------+---------+
|Modl\Srvc|IPv4-only|Separate|IPv4/6|IPv6-only|
+---------+---------+--------+------+---------+
|IPv4-only| +++ | +++ | +++ | 2,3 |
+---------+---------+--------+------+---------+
|DS w/IPv4| +++ | +++ | +++ | 1?,2,3 |
+---------+---------+--------+------+---------+
|DS w/both| +++ | +++ | +++ | +++ |
+---------+---------+--------+------+---------+
|DS w/IPv6| 1?,2,3 | +++ | +++ | +++ |
+---------+---------+--------+------+---------+
|IPv6-only| 2,3 | +++ | +++ | +++ |
+---------+---------+--------+------+---------+
The matrix is intuitive; all off-the-shelf working combinations are
listed with "+++". In the remaining four instances, the possible
transition mechanisms that could be applied are listed.
So, the easiest thing to do would be to ensure that the service or
deployment model matches one of these categories. However, some of
these are unoptimal, as they do not progress the transition.
To summarize, in the generic case, when someone providing service is
not sure who will be using it, then the service should not be
deployed IPv4-only or IPv6-only. Also, when someone is planning a
deployment of nodes, if one is not sure which services they will be
using, the nodes should not be deployed IPv4-only, dual-stack with
only IPv6 connectivity or IPv6-only.
However, in some cases sticking to this guideline is not enough, and
something more is needed.
2.3. Transition Mechanism Deployment Considerations
There are a few very important questions which must be addressed in
the cases where a transition mechanism deployment is deemed
necessary. For example:
o if I deploy IPv6-only service, whose burden is it to enable its
use by all clients I wish to make it accessible to?
o if I deploy IPv6-only nodes, or dual-stack nodes with only IPv6
connectivity, whose burden is it to enable them to access all the
services they want?
Savola [Expires August 2003] [Page 5]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
o how much easier would it be to go for dual-stack approach
instead?
The intuitive answer to both of these would appear to be: "if you
really want to shoot yourself in the foot, do not blame the person
who sold you the gun -- or at least get prepared for a big hospital
bill."
That is, it is not wise to assume IPv6 will gain enough momentum in
the short/medium term that you would not have to take care of these
issues yourself -- or get someone else (e.g. a service provider
providing extra IPv6 services) do it.
Of course, when considering an option like this, one should always be
double careful not to forget comparing the situation to the cost of
deploying a dual-stack solution. Typically, it would appear to be
the case that a dual-stack solution is much easier to cope with than
the alternative, and the total cost is less.
3. Transition Mechanism Considerations
3.1. Obtaining Connectivity
As noted in the matrix in the previous chapter, dual-stack approach
(using one of the flavours) seems vastly superior in the generic
case.
Obtaining IPv6 connectivity is an important step when moving from the
deployed base of dual-stack nodes to the use of IPv6-enabled
services. These do *not* have to happen simultaneously: indeed, it
can even be counter-productive to enable IPv6 connectivity
immediately (more of this later).
The connectivity could be classied 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)
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.
Savola [Expires August 2003] [Page 6]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
3.2. Protocol Translation
Protocol translation is used to refer to mechanisms which perform a
NAT-PT or SIIT -like automatic translation of all the packets,
regardless of content, or (typically) application compatibility.
These may work to some level of success for limited deployment
scenarios and sets of applications only, but do not seem to fulfill
robustness and simplicity principles in general.
3.3. Application Level Gateway
An ALG may actually implement a translation function, as described
above, but it is specifically deployed in such a fashion that the
translation is only applied to the applications that should work with
a relatively high expectation of success.
A typical disadvantage of ALG's is that their use, and the
applications, must be explicitly configured. This is not always the
case, and the mechanisms could be developed towards that direction,
too.
3.4. Application Proxy
It is well known that a protocol translator must have an ALG with it,
to deal with protocols (as simple as FTP) that contain direct
dependencies on IP addresses. However, ALGs may exist in the absence
of a protocol translator, and in this case they are better described
as proxies.
If all protocols of interest (e.g. SMTP, HTTP, SIP,...) are handled
by a proxy at the boundary between IPv4 and IPv6, no IP level
translation is needed.
Of course, this is not a general solution, but if such a proxy is co-
located with a firewall, and covers all protocols allowed by the
firewall, there should be no impact on users. beyond the usual
effects of the firewall.
4. A View on Transition
This section includes a few views on several aspects of the
transition.
Savola [Expires August 2003] [Page 7]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
4.1. Providing IPv6-enabled Services
Providing IPv6-enabled services is an extremely tricky business which
has a number of caveats which should be taken into serious
consideration.
First, we'll assume that in the first phase, it is crucial to improve
the number of dual-stack (even without IPv6 connectivity) nodes.
This seems a reasonably safe assumption.
Now, a potential problem appears when someone wishes to provide also
IPv6-enabled service alongside with their IPv4 service: the first
priority, for all parties, the service provider, the vendor of the
dual-stack nodes and the users is that enabling IPv6 will not degrade
the perceived performance of existing use or applications
significantly. Otherwise, only few would be willing to deploy dual-
stack nodes (or connectivity), or enable IPv6 on their services. This
also seems to be a reasonable assumption.
A temporary workaround would be to deploy the IPv6 services under
different service identifiers, like www.ipv6.example.com rather than
www.example.com. In some cases, this may severely affect the
outbound connections and cannot be done. However, 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 subdomain.
A fix for this would be changing the default address ordering to
prefer A DNS records over AAAA records: then, IPv6 addresses could be
added for standard names without worries, and the nodes themselves --
not the one implementing service -- would be capable of making a
decision when to switch the toggle the other way around.
The requirement for this problem to go away are globally stable and
robust IPv6 connectivity. It seems to take long until that is
achieved [6BMESS].
4.2. Deployment of IPv6-only Nodes
There are several issues associated with deploying IPv6-only (or in
most cases, also dual-stack w/ IPv6-only connectivity) nodes.
In particular, the question about the mechanism to access IPv4
services will be asked; it can be avoided by "don't do it then, yet",
but at some point (sooner or later), there will be a desire to deploy
IPv6-only nodes.
Savola [Expires August 2003] [Page 8]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
Some services can easily be provided through separate services or
ALG's through dual-stack nodes crafted for this purpose, or the IPv6
ISP: for example, dual-stack DNS recursive resolvers, SMTP MX
services, WWW-caches, and others.
In some ways, this has the similar conditions as the case above: a
sufficient amount of IPv6 connectivity of *good quality* is required,
as well as a way to access IPv4 services (in the general case).
4.3. Deploying IPv6-only Sites
The above two cases have already shown problems with IPv6-only
deployments, but here issues specific to IPv6-only sites are
discussed.
It is not enough to deploy IPv6 architecture internal to the site and
to provide translation/ALG service to make it possible to reach
mainstream IPv4 services.
This is because this will lead to a service outage or degradation
when trying to reach services in the Internet which are IPv6-enabled,
*unless* the network connectivity is good enough (at least near IPv4
quality) to the majority of the IPv6-enabled destinations, due to the
reasons described above.
The fixes to this are similar; first, the ALG's or translations could
be designed to prefer IPv4 services by default until explicitly
configured otherwise: then even IPv6-enabled services would be
reached using IPv4.
4.4. The Role of an IPv6 ISP
Previously, it has been stated that IPv6-enabled ISP's could provide
a certain set of solutions, in particular, in cases where the sites
try to reach an IPv6-state.
It should be noted that there are ISP's operating under different
models: some do not want to produce much other than IPv4/v6 -enabled
connectivity. Some may only provide IPv6-connectivity. However, in
the latter case, it is quite probable that the ISP is also willing to
provide services that make the life of IPv6-only users easier.
Savola [Expires August 2003] [Page 9]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
4.5. Example: DSTM
[DSTM] offers a mechanism of deploying IPv6-only network
infrastructure with dual-stack nodes with only IPv6-connectivity;
IPv4 addresses are assigned temporarily on need, and transported to
the tunnel end-point inside the site.
This offers the advantage of removing the IPv4 addressing and routing
from the most parts of the site. However, these already exist (in
older deployments), or can rather easily be configured according to
the IPv6 routing/addressing plan. The major drawbacks include the
temporarity of address assignment, and questionable observed
advantages.
It seems that the cost of deploying IPv4 addresses and routing in the
site-internal network infrastructure is very low; actually current
platforms do not even work without it. So, the model appears to be
both premature and questionable. Also, the temporary address
assignment would seem to conflict with the robustness and simplicity
principles: it may be very difficult to make such an operation work
flawlessly; the basic operation could be much simpler -- constant
IPv4 address assigned -- but then a perceived advantage of the
mechanism would be lost.
4.6. Example: TCP/UDP Relay
[RELAY] provides a mechanism to perform protocol translation on a
service-by-service basis which has decoupled interactions with DNS
from the service management.
TCP/UDP relay can be deployed at two different locations: on the
client side or the server side. On the client side, the usability
appears to be a bit questionable, bringing up many issues regarding
the interaction of protocol translation and DNS. However, on the
server side, it is much simpler.
That is, for example, a gateway between IPv4-only NNTP service and a
dual-stack relay at the NNTP service providers' network can be easily
and relatively reliably built with a TCP relay. This includes
publishing the address of the TCP relay pointing towards the NNTP
server in the DNS, configuring sufficient access-lists so that only
the NNTP service is reachable, and configuring access-lists that only
valid users have the access to use the relay service. The latter is
necessary because the IPv4-only service sees the connections
originating from the relay (and the real IPv6 source is lost); this
is unfortunate, but unavoidable.
Savola [Expires August 2003] [Page 10]
Internet Draft draft-savola-v6ops-transarch-00.txt February 2003
Of course, in most cases, deploying IPv6-enabled services from the
start is the best, and simplest choice. However, the TCP/UDP relay
seems to be sufficiently simple and robust mechanism when used for
providing a gateway for some IPv4-enabled services to the IPv6 users.
5. Acknowledgements
Discussions with Brian Carpenter gave a push to writing this memo.
6. Security Considerations
Transition architecture discussion has no special security
considerations as such; however, one must be very careful not to
introduce an new security considerations when specifying and
deploying the transition architecture.
In the quick analysis above, mainly only the robustness and
simplicity principles were considered, leaving security to follow
from these. A more careful security review will be needed in the
future.
7. References
7.1. Informative
[6BMESS] Savola, P., "Moving from 6bone to IPv6 Internet",
draft-savola-v6ops-6bone-mess-01.txt, work-in-progress,
November 2002.
[ARCH] Bush, R., Meyer, D., "Some Internet Architectural
Guidelines and Philosophy", RFC3439, December 2002.
[DSTM] Bound, J., et al., "Dual Stack Transition Mechanism",
draft-ietf-ngtrans-dstm-08.txt, expired work-in-progress,
July 2002.
[RELAY] Hagino, J., Yamamoto, K., "An IPv6-to-IPv4 Transport
Relay Translator", RFC3142, June 2001.
Author's Address
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
Savola [Expires August 2003] [Page 11]