Configure TCP/IP - MCSA Windows Server 2012 R2: Installation and Configuration Study Guide - page 430

dual stack machine can use either its IPv4 or IPv6 address to communicate on the local
network (within the local network infrastructure). ISATAP can use the neighbor discovery
mechanism to determine the router ID and network prefix where the device is located, thus
making intrasite communication possible even in a routed infrastructure.
The format of an ISATAP address is as follows:
[64bits of prefix] [32bits indicating ISATAP] [32bits IPv4 Address]
The center 32 bits indicating ISATAP are actually 0000:5EFE (when using private IPv4
addresses). The ISATAP address of the example Windows Server 2012 R2 machine using
the link-local IPv6 address is FE80::5EFE:192.168.1.200. Each node participating in the
ISATAP infrastructure must support ISATAP. If you're routing through an IPv4 cloud, a
border router (a router transitioning from an IPv6 to IPv4 space) must support ISATAP.
Windows Server 2012 R2 can be configured as a border router, and it will forward ISATAP
packets. ISATAP is experimental and is defined in RFC 4214.
6to4 6to4 specifies a procedure for IPv6 networks to communicate with each other through
an IPv4 space without the IPv6 nodes having to know what's happening. The IPv6 nodes do
not need to be dual stacked to make this happen. The border router is the device responsible
for knowing about the IPv6-to-IPv4 transition. The IPv6 packets are encapsulated at the
border router (and decapsulated at the other end or on the way back). There is an assigned
prefix for the 6to4 implementation: 2002:: /16. 6to4 is defined in RFC 3056.
Te re d o Teredo (named after a kind of shipworm that drills holes in the wood of ships) is
a protocol designed to allow IPv6 addresses to be available to hosts through one or more
layers of NAT. Teredo uses a process of tunneling packets through the IPv4 space using
UDP. The Teredo service encapsulates the IPv6 data within a UDP segment (packet) and
uses IPv4 addressing to get through the IPv4 cloud. Having a layer 4 (Transport layer)
available to use as translation functionality is what gives you the ability to be behind a
NAT. Teredo provides host-to-host communication and dynamic addressing for IPv6 nodes
(dual stack), allowing the nodes to have access to resources in an IPv6 network and the
IPv6 devices to have access to the IPv6 devices that have only connectivity to the IPv4 space
(like home users who have an IPv6-enabled operating system connecting to IPv6 resources
while their home ISP has only IPv4 capabilities). Teredo is defined in RFC 4380.
In Windows Server 2012 R2, an IPv4 Teredo server is identified and configured (using the
netsh command interface). The Teredo server provides connectivity resources (address)
to the Teredo client (the node that has access to the IPv4 Internet and needs access to an
IPv6 network/Internet). A Teredo relay is a component used by the IPv6 router to receive
traffic destined for Teredo clients and forward the traffic appropriately. The defined
prefix for Teredo address is 2001:0000:: /32. Teredo does add overhead like all the other
implementations discussed. It is generally accepted that you should use the simplest model
available. However, in the process of integration/migration for most of us behind a NAT,
Teredo will be the process to choose.
From Windows Server 2012 R2, use the ipconfig /all command to view the default
configurations including IPv4 and IPv6. You may notice a notation that I didn't discuss, the