Migrating your existing IPv4-based network
infrastructure to IPv6 requires an understanding of different IPv6
transition technologies that you can use achieve your goal. Windows
Vista and Windows Server Code Name “Longhorn” support three transition
technologies in particular:
ISATAP
Stands for Intra-Site Automatic Tunnel Addressing Protocol, an address
assignment and automatic tunneling technology defined in RFC 4214 that
you can use to provide unicast IPv6 connectivity between IPv6/IPv4
hosts (hosts that support both IPv6 and IPv4) across an IPv4-based
intranet (a private network whose infrastructure hardware, such as
routers, only supports IPv4 and not IPv6).
6to4
An address assignment and automatic tunneling technology defined in RFC
3056 that you can use to provide unicast IPv6 connectivity between
IPv6/IPv4 hosts and sites across the IPv4-based public Internet. 6to4
enables you to assign global IPv6 addresses within your private network
so that your hosts can reach locations on the IPv6 Internet without
needing a direct connection to the IPv6 Internet or an IPv6 global
address prefix obtained from an IPv6-supporting ISP. (Communication
between a 6to4 site and a native IPv6 node requires the use of a 6to4
relay, however.)
Teredo
An address assignment and automatic tunneling technology defined in RFC
4380 that you can use to provide unicast IPv6 connectivity between
IPv6/IPv4 hosts across the IPv4 public Internet when the IPv6/IPv4
hosts are located behind one or more NATs. Teredo provides similar
functionality to 6to4 but without needing edge devices that support
6to4 tunneling.
These
three IPv6 transition technologies are supported by Windows Vista,
Windows Server Code Name “Longhorn,” Windows XP Service Pack 2, and
Windows Server 2003 Service Pack 1. Of the three, ISATAP is the primary
transition technology that you should use for migrating an existing
IPv4-based intranet to IPv6; it is discussed further in the following
sections. Teredo is primarily useful in Small Office/Home Office (SOHO)
networking environments, where NAT-enabled broadband routers provide
Internet connectivity for users. (Think of Teredo as a transition
technology of last resort, because as IPv6 connectivity becomes
ubiquitous, the need for NAT traversal will decline until Teredo is no
longer needed.)
|
Teredo
is intended to be a consumer technology and is generally not
recommended for enterprises. This is because Teredo requires that the
edge device allow all outbound UDP traffic. For example, because of
security reasons, many enterprise administrators do not want client
computers on the corporate network to be directly accessible from the
Internet, and in that case turning off Teredo is a good idea.
If
administrators want to disable Teredo on their client computers or
simply prevent it from working, they can do so in one of three ways:
Block all outbound UDP traffic by default Block name resolution of the Teredo DNS hostname, which by default on Windows Vista computers is teredo.ipv6.microsoft.com Use
Group Policy or a script to create the following DWORD registry value,
which turns off Teredo on targeted Windows Vista computers (this
registry setting is not exposed by default in Group Policy but can be
pushed down using a custom ADMX file): HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents
The settings you can specify for this value are:
If
administrators want to support only native IPv6 in their networks, or
if they don’t want to support any IPv6 traffic until they deploy native
IPv6, they can choose to turn off all tunneling technologies using the
second choice in the preceding list.
|
Understanding ISATAP
By
default, the IPv6 protocol in Windows Vista automatically configures a
link-local unicast IPv6 address of the form FE80::5EFE:w.x.y.z. This
address is called the ISATAP address and it is assigned to the ISATAP
tunneling interface. Using their ISATAP addresses, two ISATAP hosts
(such as Windows Vista computers) can communicate using IPv6 by
tunneling across an IPv4-only network infrastructure (such as a network
whose routers forward only IPv4 packets and not IPv6 packets).
With
the addition of one or more ISATAP routers (IPv6-enabled routers that
advertise address prefixes, forward packets between ISATAP hosts and
other ISATAP routers, and act as default routers for ISATAP hosts) a
variety of transition topologies become possible, including:
These
configurations are possible because ISATAP routers advertise address
prefixes that enable ISATAP hosts (such as Windows Vista computers) to
autoconfigure global, site-local, or unique local unicast IPv6
addresses. Without the presence of an ISATAP router, ISATAP hosts can
only autoconfigure link-local unicast IPv6 addresses, which limits IPv6
communications to between hosts on the IPv4-only intranet.
|
The
ISATAP interface name is based on the DNS setting of the primary IPv4
interface of this ISATAP interface. For example, if the DNS suffix
assigned to the primary IPv4 interface of this ISATAP interface is
contoso.com, the ISATAP interface name will be isatap.contoso.com.
An
alternate form of the ISATAP interface name is isatap.{GUID} where GUID
is a globally unique identifier. However, this GUID form is used to
name the ISATAP interface only if there is no DNS suffix setting on the
primary IPv4 interface.
Xinyan Zan, Technical Lead
IPv6 Transition Technology
|
Migrating an Intranet to IPv6
Best
practices for migrating existing IPv4-based network infrastructures to
IPv6 are still evolving. Therefore, this section presents a general
outline of how to migrate an intranet to IPv6 and provides references
to more detailed information on the subject for interested readers.
The
ultimate goal of IPv4 to IPv6 migration is to achieve an IPv6-only
network infrastructure that has IPv6-only hosts. From a practical
standpoint, however, the lesser goal of achieving a network
infrastructure that supports both IPv6 and IPv4—and where hosts also
support both IPv6 and IPv4 but use mainly IPv6—is a more reasonable
goal to aim for. Achieving this goal is a lengthy process that involves
seven main steps:
1. | Upgrading your applications and services
|
2. | Preparing your DNS infrastructure
|
3. | Preparing your DHCP infrastructure
|
4. | Upgrading your hosts
|
5. | Migrating from IPv4-only to ISATAP
|
6. | Upgrading your routing infrastructure
|
7. | Migrating from ISATAP to native IPv6
|
Upgrading Your Applications and Services
To
prepare your applications and services for migration, you will need to
upgrade existing applications and services to support IPv6 in addition
to IPv4. This may require upgrades from ISVs and third-party vendors or
custom coding on your part. While the ultimate goal is for all your
applications and services to run native IPv6, a more appropriate target
is to ensure that they work with both IPv4 and IPv6.
Preparing Your DNS Infrastructure
You
must prepare your DNS infrastructure to support the AAAA records used
to resolve DNS names to IPv6 addresses. This might require upgrading
your existing DNS servers. The DNS Server service of Windows Server
2003 supports dynamic registration of AAAA records for unicast IPv6
addresses (excluding link-local addresses).
Preparing Your DHCP Infrastructure
You
should prepare your DHCP infrastructure to support DHCPv6 for automatic
assignment of global, site-local, and/or unique local unicast IPv6
addresses or configuration settings for IPv4/IPv6 nodes on your
network. By using DHCPv6, an IPv6 host can obtain subnet prefixes and
other IPv6 configuration settings. A common use of DHCPv6 is to
configure Windows Vista–based client computers with the IPv6 addresses
of DNS servers on the network. (DNS servers are not configured through
IPv6 router discovery.)
The DHCP Server
service in Windows Server 2003 does not support stateful address
autoconfiguration or the DHCPv6 protocol. The DHCP Server role in
Windows Server Code Name “Longhorn,” however, will support both
stateful and stateless IPv6 address autoconfiguration using DHCPv6. The
DHCP Client service in Windows Vista and Windows Server Code Name
“Longhorn” does support address autoconfiguration using DHCPv6.
Just
as with DHCP with IPv4, you also need to deploy and configure DHCPv6
relay agents for each subnet containing Windows Vista clients. Many
hardware routers already support a DHCPv6 relay agent. You must
configure relay agents with the IPv6 addresses of the DHCPv6 servers on
your network. Relay agents can be configured but should not be enabled
until you deploy IPv6 routing on your subnets.
Upgrading Your Hosts
You
may need to upgrade some of your hosts until all your hosts support
both IPv6 and IPv4. Windows platforms from Windows XP Service Pack 2
onward support both IPv4 and IPv6, though full support for IPv6
functionality for built-in programs and services is only provided in
Windows Vista and later.
Migrating from IPv4-only to ISATAP
Once
you’ve prepared your applications, services, hosts, and DNS/DHCP
infrastructure, you can begin deploying ISATAP routers to create
islands of IPv6 connectivity within your IPv4-based intranet. You will
need to add A records to the appropriate DNS zones so that your ISATAP
hosts can determine the IPv4 addresses of your ISATAP routers.
You
may decide to deploy zero or more ISATAP routers for inter-ISATAP
subnet routing within your intranet, depending on the size of your
intranet and the geographical distribution of its sites. You may decide
to deploy redundant ISATAP routers to provide consistent availability
of IPv6 address prefixes and other configuration settings for your
ISATAP hosts. You will also likely deploy one or more ISATAP routers to
provide IPv6 connectivity between your IPv4-based network
infrastructure and the public IPv6 Internet as this evolves.
Upgrading Your Routing Infrastructure
Once
you have deployed ISATAP to enable IPv6 hosts to communicate over your
IPv4 network infrastructure, you should begin upgrading your network
infrastructure (including routers, gateways, and other access devices)
to support IPv6. Rather than upgrading your infrastructure to support
only IPv6, a more reasonable upgrade goal is dual IPv4/IPv6 support. In
many cases, actual replacement of router hardware is not necessary.
Because many modern hardware routers support both IPv4 and IPv6
routing, the task of upgrading of your routing infrastructure to
support IPv6 becomes configuration, not replacement. As you enable IPv6
routing support for a subnet, also enable the DHCPv6 relay agent for
the subnet.
Typically, you will begin
upgrading your routing infrastructure early in your ISATAP deployment
by upgrading the core routers on your network backbone to support IPv6.
This will create islands of ISATAP hosts that connect to this backbone
to communicate with other IPv6 hosts anywhere in your intranet.
Migrating from ISATAP to Native IPv6
Finally,
when all your network infrastructure devices support IPv6, you can
begin to decommission your ISATAP routers because you no longer need
them. Whether you will also migrate your infrastructure and hosts to
support only pure-IPv6 is a decision best left for the distant future.
