Logo - tutorial.programming4.us
Windows XP
Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Vista

Deploying IPv6 : Planning for IPv6 Migration - Understanding ISATAP, Migrating an Intranet to IPv6

12/30/2014 3:12:51 AM
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.)

How It Works: Blocking Teredo

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):


    The settings you can specify for this value are:

    • 0x10 Setting this value will disable Teredo only on the computer.

    • 0x01 Setting this value will disable all tunnel interfaces on the computer.

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:

  • Connecting ISATAP hosts on an IPv4-only intranet to an IPv6-capable network

  • Connecting multiple “islands” of ISATAP hosts through an IPv6-capable backbone

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.

Direct From the Source: ISATAP Interface Name

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:

Upgrading your applications and services

Preparing your DNS infrastructure

Preparing your DHCP infrastructure

Upgrading your hosts

Migrating from IPv4-only to ISATAP

Upgrading your routing infrastructure

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.

Other -----------------
- Configuring and Troubleshooting IPv6 in Windows Vista (part 4) - Troubleshooting IPv6 Connectivity
- Configuring and Troubleshooting IPv6 in Windows Vista (part 3) - Configuring IPv6 in Windows Vista Using Netsh , Other IPv6 Configuration Tasks
- Configuring and Troubleshooting IPv6 in Windows Vista (part 2) - Configuring IPv6 in Windows Vista Using the User Interface
- Configuring and Troubleshooting IPv6 in Windows Vista (part 1) - Displaying IPv6 Address Settings
- Deploying IPv6 : IPv6 Enhancements in Windows Vista
- Creating an XPS Document,Scanning a Picture, Scanning Anything
- Printing Your Photographs, Printing Web Pages - Print the Pictures, Fix the Layout
- Specifying a Default Printer, Controlling Your Printing - Change the Default Printer, View the Queue, Stop the Presses
- Printing from a Program, Printing a Document - Print a Document Using the Default Printer, Print a Document Using a Specific Printer
- Understanding IPv6 (part 3) - Understanding Address Autoconfiguration, Understanding Name Resolution
Top 10
- Microsoft Exchange Server 2013 : Working with cmdlets (part 2) - Understanding cmdlet errors, Using cmdlet aliases
- Microsoft Exchange Server 2013 : Working with cmdlets (part 1) - Using Windows PowerShell cmdlets, Using cmdlet parameters
- Microsoft Exchange Server 2013 : Using Windows PowerShell (part 2) - Running and using cmdlets, Running and using other commands and utilities
- Microsoft Exchange Server 2013 : Using Windows PowerShell (part 1) - Running and using Windows PowerShell
- Troubleshooting Stop Messages : Being Prepared for Stop Errors - Prevent System Restarts After a Stop Error
- Troubleshooting Stop Messages : Memory Dump Files (part 3) - Using Memory Dump Files to Analyze Stop Errors - WinDbg Debugger
- Troubleshooting Stop Messages : Memory Dump Files (part 2) - Using Memory Dump Files to Analyze Stop Errors - Using Problem Reports And Solutions
- Troubleshooting Stop Messages : Memory Dump Files (part 1) - Configuring Small Memory Dump Files, Configuring Kernel Memory Dump Files
- Troubleshooting Stop Messages : Stop Message Overview - Identifying the Stop Error, Finding Troubleshooting Information
- Deploying IPv6 : Planning for IPv6 Migration - Understanding ISATAP, Migrating an Intranet to IPv6