Subject: (ngtrans) transition scenario

From: Laurent Toutain <[email-masked]>
Date: Tue, 11 May 1999 11:33:56 +0200

Hi Alain, few weeks ago you asked for our vision of the transition
process.

I think there is two different kinds of situation for transition
scenarios. The first one is for totally new networks (such a in an
house-build network or it could also be the case with GSM data network).
In this scenario, the boundary between IPv4 and IPv6 is clear. The
second scenario is when you want to migrate to IPv6 a existing IPv4
network.
I will focus on the second scenario and gives the 4 step for such a
migration. In fact, and I will discuss it at the end at the forth step
the two scenarios are converging.

We must avoid any blocking situation. It means that there is no D-day
for the network equipments, for end-system or for applications. If a
company cannot migrate one of this component, the transition will be
delayed. So the goal of this proposal is to remove such blocking
situations, to start the transition as soon as possible.

The scenario can be divided in four steps. At each step some tools are
needed. We will focus on different case for each of these steps :

-   applications (those compiled for IPv4 and those compiled for IPv6).
    for the end systems : four possible initiated dialogs (IPv6 -> IPv6,

    IPv6 -> IPv4, IPv4 -> IPv6, IPv4 -> IPv4).
    Note that IPv6->IPv4 and IPv4->IPv6 are not symmetrical. The most
    difficult case is when a IPv4-only  equipment wants to talk with a
v6
    equipment, since the v4 cannot be modified. Note also that a v4
    equipment can either designate the destination using a name
registered
    in the DNS or directly v4 address.

-   for intermediary systems (contains IPv4 and/or IPv6 routing table)
-   for providers (provide a v4 only, v6 only or v4/v6 access)

One way to avoid blocking is to also break the chicken and egg problem
(providers are waiting for customers and customers are waiting for
providers). I think one way is to promote IPv6 inside the domain and not
wait for IPv6 providers (even if 6bone and other native IPv6 networks
are good things for IPv6 deployment, but they are not in the scope of
this document). The «killer application» to promote IPv6 inside a domain
is, in my opinion, to focus on the plug and play capabilities (at least
of end systems) but we have to add some security features.

The end-user must, of course, not be aware of IPv6 addresses, but the
system engineers must also have something easy to configure, especially
during the transition period. I think some of them are afraid to learn
something that can be viewed as a new protocol. So the tool we will have
to develop for the transition must take in account this constraint and
be as much as possible plug and play.

The transition will introduce extra steps in packet routing, but the
extra processing power will decrease in time since v6 networks will
grow. It is the opposite with v4 applications such as NAT, the
complexity will increase with the v4-network growth.

The first 3 steps I will develop focus on migration inside a domain. We
suppose that the access provider is still v4-only. The last step focus
on a v6-only access provider (which allow of course the access to the v4
world). This scenario is compatible with 6bone or IPv6 native entwork
deployement.

First Step - current state (RFC 1933)
=====================================

In the first step equipments have a totally configured dual stack (i.e.
they have a v4 and v6 address). Routers have routing table for v4 and
v6. Note that we are currently in this first step with the experiment
done in the 6bone.

Applications
------------
v4 compiled
    the only way is to use the v4 stack.
v6 compiled
    the mapped IPv4 addresses allows communication either with IPv4
    or IPv6 equipments. If the other side is v4, the v4 stack is used.

End Systems
-----------
IPv6 -> IPv6
    A DNS call answers a v6 address. The dialog is naturally established

    using the IPv6 stack and the IPv6 routing table inside routers.
IPv6 -> IPv4
    A DNS call answers a v4 address, the dialog is established using the

    IPv4 stack and the v4 routing table inside routers.
IPv4 -> IPv6
    The v4 equipment request the v4 address and establishes the dialog
    using its v4 stack and the v4 routing table inside routers.
IPv4 -> IPv4
    Same thing as above

Intermediary systems inside domains
-----------------------------------
IPv4-only routing table
    In this case IPv6 packets are hidden inside v4-tunnels (6bone
configuration).
    This is mainly used between v6 clouds
IPv4/IPv6 routing table
    Inside v6 clouds, routers proceed v4 and v6 packets.
IPv6-only routing table
    This is an evolution of the 6bone between v6 clouds. v4 and v6
packets
    will not follow the same path.

provider
--------
v4-only
    current situation. the provider routes only v4 packet. v6
connectivity
    can be obtain through tunneling, using a virtual provider
v4/v6
    can be in the scope of this scenario to link different clouds.
v6-only
    not at this step of the transition

tools needed
------------
DNS
    to register either v4 or v6 addresses

This step allows to test protocols, how to manage the network, but
doesn’t solve the problems due to the lack of IPv4 addresses since every
equipment must have their double stack configured.

Second Step - AIIH
==================

Remove static configuration of the IPv4 stack, routers continue to route
v4 and v6. Allocate v4 addresses just when needed. This reduce the need
for v4 addresses.

Applications
----------------
v4 compiled
    the only way is to use the v4 stack. (see next table for v4
configuration)
v6 compiled
    the mapped IPv4 addresses allows communication either with IPv4 or
IPv6
    equipments. If the other side is v4, the v4 stack is used. (see next
table
    for v4 configuration)

End Systems
-----------

IPv6 -> IPv6
    No change from previous step. A DNS call answers a v6 address. The
dialog
    is naturally established using the IPv6 stack and the IPv6 routing
table
    inside routers.
IPv6 -> IPv4
    The DNS call answers a v4 address or the application is configured
    directly with a v4 address. The end-system must required a v4
address
    during the dialog. DHCPv4 can be used without any modification.
IPv4 -> IPv6
    The v4 equipment asks the DNS for a v4 address, the DNS instead of
error
    message allocated temporary an v4 address to the destination. This
is
    described in AIIH draft.
    If the v4-only equipment handle only a v4 destination address (not a
name),
    a v4 address must be statically assigned the destination.
IPv4 -> IPv4
    No change from previous step. The v4 equipment request the v4
address and
    establishes the dialog using its v4 stack and the v4 routing table
inside
    routers.

Intermediary systems inside domains
----------------------------------------------
IPv4-only  routing table
    No change from previous step. In this case IPv6 packets are hidden
inside
    v4-tunnels (6bone configuration). This is mainly used between v6
clouds.
IPv4/IPv6 routing table
    No change from previous step. Inside v6 clouds, routers proceed v4
and v6
    packets.
IPv6-only routing table
    No change from previous step. This is an evolution of the 6bone
between v6
    clouds. v4 and v6 packets will not follow the same path.

provider
-----------
v4-only
    No change from previous step. current situation. the provider routes
only v4
    packet. v6 connectivity can be obtain through tunneling, using a
virtual
    provider
v4/v6
    No change from previous step. can be in the scope of this scenario
to link
    different clouds.
v6-only
    No change from previous step. not at this step of the transition

tools needed
----------------
DNS
    to register either v4 or v6 addresses.
DHCPv4
    to allocate dynamically addresses to v6 equipments
AIIH
    define a way to allocate dynamically v4 address when a request
arrive to the
    DNS (AIIH include DHCPv4)

At this step the DHCP server is "difficult" to configure since the
network topology must be taken into account to allocate dynamically IPv4
addresses.

Some security problems come from deny of services if someone outside ask
to talk with all the v6 equipment inside the domain.

Third Step - DTI
================

At this step, the IPv4 configuration should be removed for routers. v4
addresses are always allocated dynamically, but they loose their locator
functionality, they remain only identificator. It is easier to manage
dynamic allocation since only unicity has to be maintain.

Applications
---------------
v4 compiled
    the only way is to use the v4 stack but linked to the dti interface
if
    possible. (see next table for v4 configuration)
v6 compiled
    the mapped IPv4 addresses allows communication either with IPv4 or
IPv6
    equipments. If the other side is v4, the v4 stack is used. (see next
table
    for v4 configuration)

End Systems
-----------
IPv6 -> IPv6
    No change from previous step. A DNS call answers a v6 address. The
dialog is
    naturally established using the IPv6 stack and the IPv6 routing
table inside
    routers.
IPv6 -> IPv4
    The DNS call answers a v4 address or the application is configured
directly
    with a v4 address. The end-system must required a v4 address during
the
    dialog. DHCPv4 can be used without any modification. Then the packet
is
    tunneled using the DTI interface
IPv4 -> IPv6
    The v4 equipment asks the DNS for a v4 address, the DNS instead of
error
    message allocated temporary an v4 address to the destination. This
is
    described in AIIH draft.

    two cases are possible when sending v4 :
        - if the host can run the dti interface, then the routing table
of the
        host indicate that all the v4 packet have to go through the dti
interface
        which will do the v4 tunneling over v6.
        - if the host cannot be modified, then a default routing table
entry
        will allow to send packets to the tunneling box that will do the

        encapsulation.

    To receive v4 packet two cases are also possible :
        - if the kernel can be modified, the v6 tunnel gives the packet
to
        the v4 stack
        - if the kernel cannot be modified, then the packet are sent to
the
        tunneling box that decapsulate the packet and send the v4 packet
natively
        on the last link

    If the v4-only equipment handle only a v4 destination address (not a
name),
    a v4/v6 mapping must be statically assigned in the transition DNS.
IPv4 -> IPv4
    can be authorized if equipment are on the same link,
    otherwise v6 tunneling must be used.

Intermediary systems inside domains
----------------------------------------------
IPv4-only  routing table
    not implemented inside the cloud
IPv4/IPv6  routing table
    not implemented inside the cloud, but at the boundary
IPv6-only routing table
    inside the cloud.

provider
----------
v4-only
    No change from previous step. current situation. the provider routes
only
    v4 packet. v6 connectivity can be obtain through tunneling, using a
virtual
    provider
v4/v6
    No change from previous step. can be in the scope of this scenario
to link
    different clouds.
v6-only
    No change from previous step. not at this step of the transition

tools needed
----------------
DNS
    to register either v4 or v6 addresses.
    to make the conversion between v4 and v6 addresses (use reverse DNS)

DHCPv4
    to allocate dynamically addresses to v6 equipments
AIIH
    define a way to allocate dynamically v4 address when a request
arrive
    to the DNS,
dti interface
    to encapsulate v4 packets into v6. In FreeBSD, we did it with a
minimum effort
    using PATRICIA tree and external resolution. Is it possible on every

    systems ?
tunneling box
    encapsulate/decapsulate packets for equipment unable to proceed IPv6

    packets, could be include in IPv6 routers.

At this phase the domain or some clouds in the domain can be view as
v6-only (even if some equipments are still using v4 addresses), but we
assume that the provider is still v4-only.

The v4 traffic need inside the domain must be reduced. One way is to
promote ALG. For example, for web applications, a proxy can be installed
at the border. The clients send their request in v6 and the proxy in v4.
Same thing for the mail.

Fourth Step - IPv6 provider
===========================

At this point, we can be in the scope of header translation since the
border between v4 and v6 is clear. Another solution is to extend the
tunneling facilities to the provider. This must be done carefully. For
example, it means that the v4 addresses given temporary to v6 hosts
belong the the provider to route v4 packets to the provider tunneling
box.