|
IPv4 and IPv6 are incompatible protocols. For this reason, transition to the new protocol
cannot be expected to be painless, and will involve significant costs for Service Providers
and customers alike. However, the costs of transition must be compared with the costs of
non-transition, or in other words, the costs of making IPv4 evolve to support new services.
Such a comparison can help us identify the best time to start the transition process,
case by case.
Whenever transition begins, one thing is certain: there will be no single "flag day" on
which the all-IPv4 network turns, as if by magic, into an IPv6 network. At the Internet
level, transition will be a lengthy process, with the two protocols existing side by side
for many years to come.
To facilitate transition, the IETF has set up a work group called
ngtrans (Next Generation TRANSition) which specifies mechanisms
for supporting interoperability between IPv4 and IPv6. In particular, the
group has focused on two major problems:
- How to make IPv6 terminals communicate with IPv4 terminals.
- How to transport IPv6 over an IPv4 network so that IPv6 "islands" interconnected via
the IPv4-based Internet can communicate.
This second problem, which is extremely important in the initial stage of IPv6 deployment,
will be joined in the future by the reciprocal problem: how to transport IPv4 over IPv6.
For the moment, however, discussions of this issue have been postponed until such time as
IPv6's presence on the Internet reaches significant proportions. Work on these problems
has led to the development of a set of transition mechanisms, each targeted to a
particular range of uses and applications.
Communication between IPv4 and IPv6 terminals
The basic approach for permitting all communications is the so-called dual stack IP,
where each new host, server, router or other item of equipment dealing with the IP level
can support both protocols. In this way, communication between IPv6 terminals takes place
directly, while an IPv4/IPv6 terminal which must communicate with an IPv4-only terminal
can do so in IPv4. This approach is not particularly burdensome for hosts and servers,
as it is a software upgrade which has no significant impact on the system. Nevertheless,
the main drawback of this approach is the need to maintain a multi-protocol network with
a double routing infrastructure, which increases administrators' work load. In addition,
generalized use of the dual stack IP model will not be possible when address space
exhaustion reaches the point that new IPv4 addresses can no longer be assigned.
To overcome these problems, several solutions for interoperation between IPv6-only networks
and IPv4-only networks have been specified which permit end-to-end communication between
heterogeneous terminals:
- Dual stack IP ALG devices which make it possible to perform protocol
translation at the borders between non-homogeneous networks through the use of
application proxies implemented on dual stack servers.
- NAT-PT (Network Address Translator - Protocol Translator)
devices (RFC2766),
which make it possible to perform address and protocol translation at the borders between
non-homogeneous networks at IP level.
- The Dual Stack Transition Mechanism, or DSTM, which proposes to use the dual
stack IP approach on the basis of IPv4 addresses assigned dynamically only when needed,
and the use of IPv4 over IPv6 tunneling in order to cross the local IPv6 network before
accessing the outer IPv4 network.
Though these transition mechanisms have the same shortcomings as the similar mechanisms
proposed for interconnecting separate IPv4 networks, they provide a significant advantage
for the future. Thus, while the mechanisms for IPv4 are final, and can no longer be done
without, those for the transition towards IPv6 are instrumental in ensuring coexistence
between IPv4 and IPv6, which should come to an end once the Internet operates entirely
under IPv6.
IPv6 over IPv4 transport
The basic technique for transporting IPv6 over IPv4 is tunneling, which involves
encapsulating IPv6 packets in IPv4 packets so that they can be carried across
IPv4 portions of the network. A tunnel is a link between two IPv4 end-points that
must be configured by specifying the IPv6 destinations (an address or a prefix) for
which the packets are to be encapsulated, and the remote IPv4 end-point to which they
must be sent. In the simplest case, the network administrator configures tunnels manually
by agreement with the administrator of the network where the remote IPv4 end-point resides.
This type of tunneling is usually called static tunneling. Most of the interconnections
between IPv6 networks used in the worldwide
6Bone è
initiative are set up through static tunneling.
However, having to deal with large numbers of tunnels, as is necessary for user connections,
causes an enormous administrative work load for network managers and makes it necessary
to develop automatic tunnel configuration mechanisms. A number of variations have been
proposed for this type of tunneling, called dynamic tunneling. The first proposal
(RFC2893),
based on the use of IPv6 addresses generated automatically from source and destination
IPv4 addresses (IPv4-compatible addresses) was not widely accepted, as the fact that it
calls for importing IPv4 routing tables into the IPv6 routing infrastructure effectively
precludes optimal hierarchical routing.
The most interesting solutions, each of which has its own area of application,
are as follows:
- 6over4 (RFC2529),
whereby IPv6 packets can be automatically encapsulated over an IPv4 network in which the
IP multicast service is enabled so that IPv6 sees the entire network as a single LAN
(Local Area Network). This makes it possible to determine the remote IPv4 end-point
automatically through the new protocol's native mechanisms. This solution poses
scalability problems, and is hampered by the fact that the IP multicast service is not
yet generally available on the Internet. For these reasons, it is an effective solution
only for corporate or campus networks which support IP multicast
- 6to4 (RFC3056),
where a method for constructing IPv6 addresses automatically from IPv4 addresses is
defined which is an improvement over the use of IPv4-compatible addresses.
This technique makes it extremely easy for IPv4 "islands" located in an IPv4 network
to communicate with each other. However, a number of problems remain for communication
between an isolated IPv6 network and the IPv6 Internet, which is developing on the
basis of a unicast addressing approach other than that envisaged by 6to4.
- IPv6 Tunnel Broker (RFC3053),
an approach that involves using dedicated servers which automatically configure tunnels
on behalf of users. This technique is particularly suitable for connections between small
users (i.e., the traditional users of dial-up Internet connectivity) and an IPv6 Service
Provider.
IPv6 Tunnel Broker
The IPv6 Tunnel Broker (RFC3053) is an
IPv4-to-IPv6 transition tool developed through CSELT's participation in the IETF
ngtrans work group.
The IPv6 Tunnel Broker provides an automatic configuration service for IPv6 over
IPv4 tunnels to users connected to the IPv4 Internet (the requirement is that there
be IPv4 connectivity between the user and the service provider: this is most commonly
provided via the Internet, though a private IPv4 network may also be used).
The service operates as follows:
- The user contacts the Tunnel Broker and goes through a registration procedure,
for example by filling out a Web form used as the service's home page. It is recommended
that https (secure http) be used to protect the user's privacy. In return, the user
receives a pair which he will use to access the service.
- The user contacts the Tunnel Broker again and, after authentication, provides
minimum information concerning his terminal's configuration (IP address, operating
system, IPv6 support software).
- The Tunnel Broker configures the network side end-point, the DNS Server and
the user terminal.
- At this point, the tunnel is active and the user is connected to the IPv6 network.
The user can change or remove his tunnel in complete security by accessing the TB
again with his <username, password>. In addition, the Tunnel Broker administrator
can monitor users' activities in order to ensure compliance with service access policies.
References
- [RFC2766]
G. Tsirtsis e P. Srisuresh, Network Address Translation - Protocol Translation (NAT-PT),
RFC2766, Feb. 2000
- J. Bound, L. Toutain, F. Dupont, H. Afifi e A. Durand, Dual Stack Transition Mechanism (DSTM),
draft-ietf-ngtrans-dstm-04.txt, Gen. 2001
- [RFC2893]
R. Gilligan e E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, RFC2893, Ago. 2000
- [RFC2529]
B. Carpenter e C. Jung, Transmission of IPv6 over IPv4 Domains without Explicit Tunnels,
RFC2529, Mar 1999
- [RFC3056]
B. Carpenter e K. Moore, Connection of IPv6 Domains via IPv4 Clouds, RFC3056, Feb. 2001
- [RFC3053]
A. Durand, P. Fasano, I. Guardini e D. Lento, IPv6 Tunnel Broker, RFC3053, Feb. 2001
|
