Outlining Windows Server 2008 R2 IPv6 Support
213
FIGURE 7.8 Enabling universal group caching in a site.
Understanding How AD Avoids Full Synchronization of Global Catalog
with Schema Changes
In the original version of Active Directory, any schema modifications would force a
Intersite Topology Generator Algorithm Improvements
The intersite topology generator (ISTG) portion of the Knowledge Consistency Checker
(KCC) has been updated to allow AD environments to scale to site structures of up to
5,000 sites. Previous limitations to the Windows 2000 ISTG essentially kept AD implementations effectively limited to 1,000 sites. This improvement, however, is available only
when all domain controllers in your AD DS environment are at least Windows Server
2003 systems and the forest functional level has been raised to Windows Server 2003 or
2008 level.
Outlining Windows Server 2008 R2 IPv6 Support
When the original structure of the Internet was taking shape, an addressing scheme was
formulated to scale to a large number of hosts. From this thinking came the original
design of the Internet Protocol, which included theoretical support for around 4 billion
7
complete resynchronization of the global catalog with all domain controllers across an
enterprise. This made it extremely ominous to institute any type of schema modifications
because replication modifications would increase significantly following schema modifications. Windows Server 2003 or 2008 environments do not have this limitation, however,
and schema modifications are incrementally updated in the global catalog.
214
CHAPTER 7
Active Directory Infrastructure
addresses, or 232. The thinking at the time was that this would be more than enough
addresses for all hosts on the Internet. This original design gave birth to the IP address
structure that is common today, known as dotted-decimal format (such as
12.155.166.151). At the time, this address space filled the addressing needs of the Internet.
However, it was quickly discovered that the range of addresses was inadequate, and
stopgap measures such as Network Address Translation (NAT) were required to make more
efficient use of the available addresses.
In addition to an inadequate supply of available addresses, the Internet Protocol version 4
(IPv4), as it is known, did not handle routing, IPSec, and QoS support very efficiently. The
need for a replacement to IPv4 was evident.
In the early ’90s, a new version of the Internet Protocol, known as Internet Protocol
version 6 (IPv6), was formulated. This design had several functional advantages to IPv4,
namely a much larger pool of addresses from which to choose by allowing for 2128 theoretical IP addresses, or over 340 undecillion, which gives more than enough IP addresses for
every square centimeter on the earth. This protocol is the future of Internet addressing,
and it’s vitally important that an operating system support it.
Windows Server 2008 R2 comes with a version of IPv6 installed, and is fully supported as
part of the operating system. Given the complexity of IPv6, it will undoubtedly take some
time before it is adopted widely, but understanding that the support exists is the first step
toward deploying it widely.
Defining the Structure of IPv6
To say that IPv6 is complicated is an understatement. Attempting to understand IPv4 has
been difficult enough for network engineers; throw in hexadecimal 128-bit addresses, and
life becomes much more interesting. At a minimum, however, the basics of IPv6 must be
understood as future networks will use the protocol more and more as time goes by.
IPv6 was written to solve many of the problems that persist on the modern Internet today.
The most notable areas that IPv6 improved upon are the following:
 Vastly improved address space—The differences between the available addresses
from IPv4 to IPv6 are literally exponential. Without taking into account loss because
of subnetting and other factors, IPv4 could support up to 4,294,967,296 nodes. IPv6,
on the other hand, supports up to 340,282,366,920,938,463,463,374,607,431,
768,211,456 nodes. Even taking into account IP addresses reserved for overhead,
IPv6 authors were obviously thinking ahead and wanted to make sure that they
wouldn’t run out of space again.
 Improved network headers—The header for IPv6 packets has been streamlined,
standardized in size, and optimized. To illustrate, even though the address is four
times as long as an IPv4 address, the header is only twice the size. In addition, by
having a standardized header size, routers can more efficiently handle IPv6 traffic
than they could with IPv4.
Outlining Windows Server 2008 R2 IPv6 Support
215
 Native support for automatic address configuration—In environments where
manual addressing of clients is not supported or desired, automatic configuration of
IPv6 addresses on clients is natively built in to the protocol. This technology is the
IPv6 equivalent to the Automatic Private Internet Protocol Addressing (APIPA)
feature added to Windows for IPv4 addresses.
 Integrated support for IPSec and QoS—IPv6 contains native support for IPSec
encryption technologies and Quality of Service (QoS) network traffic optimization
approaches, improving their functionality and expanding their capabilities.
Understanding IPv6 Addressing
An IPv6 address, as previously mentioned, is 128 bits long, as compared with IPv4’s 32-bit
addresses. The address itself uses hexadecimal format to shorten the nonbinary written
form. Take, for example, the following 128-bit IPv6 address written in binary:
111111101000000000000000000000000000000000000000000000000000000000
00001000001100001010011111111111111110010001000111111000111111
The first step in creating the nonbinary form of the address is to divide the number in 16bit values, as follows:
1111111010000000 0000000000000000
0000000000000000 0000000000000000
0000001000001100 0010100111111111
Each 16-bit value is then converted to hexadecimal format to produce the IPv6 address:
FE80:0000:0000:0000:020C:29FF:FE44:7E3F
Luckily, the authors of IPv6 included ways of writing IPv6 addresses in shorthand by
allowing for the removal of zero values that come before other values. For example, in the
address listed previously, the 020C value becomes simply 20C when abbreviated. In addition to this form of shorthand, IPv6 allows continuous fields of zeros to be abbreviated by
using a double colon. This can only occur once in an address, but can greatly simplify the
overall address. The example used previously then becomes the following:
FE80:::20C:29FF:FE44:7E3F
NOTE
It is futile to attempt to memorize IPv6 addresses, and converting hexadecimal to decimal format is often best accomplished via a calculator for most people. This has
proven to be one of the disadvantages of IPv6 addressing for many administrators.
7
1111111001000100 0111111000111111
216
CHAPTER 7
Active Directory Infrastructure
IPv6 addresses operate much in the same way as IPv4 addresses, with the larger network
nodes indicated by the first string of values and the individual interfaces illustrated by the
numbers on the right. By following the same principles as IPv4, a better understanding of
IPv6 can be achieved.
Migrating to IPv6
The migration to IPv6 has been, and will continue to be, a slow and gradual process. In
addition, support for IPv4 during and after a migration must still be considered for a
considerable period of time. It is consequently important to understand the tools and
techniques available to maintain both IPv4 and IPv6 infrastructure in place during a
migration process.
Even though IPv6 is installed by default on Windows Server 2008 R2, IPv4 support
remains. This allows for a period of time in which both protocols are supported. After
migrating completely to IPv6, however, connectivity to IPv4 nodes that exist outside of
the network (on the Internet, for example) must still be maintained. This support can be
accomplished through the deployment of IPv6 tunneling technologies.
Windows Server 2008 R2 tunneling technology consists of two separate technologies. The
first technology, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP), allows for
intrasite tunnels to be created between pools of IPv6 connectivity internally in an organization. The second technology is known as 6to4, which provides for automatic intersite
tunnels between IPv6 nodes on disparate networks, such as across the Internet. Deploying
one or both of these technologies is a must in the initial stages of IPv6 industry adoption.
Making the Leap to IPv6
Understanding a new protocol implementation is not at the top of most people’s wish
lists. In many cases, improvements such as improved routing, support for IPSec, no NAT
requirements, and so on are not enough to convince organizations to make the change.
The process of change is inevitable, however, as the number of available nodes on the
IPv4 model decreases. Consequently, it’s good to know that Windows Server 2008 R2 is
well prepared for the eventual adoption of IPv6.
Detailing Real-World Replication Designs
Site topology in Windows Server 2008 R2’s AD DS has been engineered in a way to be
adaptable to network environments of all shapes and sizes. Because so many WAN topologies exist, a subsequently large number of site topologies can be designed to match the
WAN environment. Despite the variations, several common site topologies are implemented, roughly following the two design models detailed in the following sections.
Detailing Real-World Replication Designs
217
These real-world models detail how the Windows Server 2008 R2 AD site topology can be
used effectively.
Viewing a Hub-and-Spoke Replication Design
CompanyA is a glass manufacturer with a central factory and headquarters located in
Leuven, Belgium. Four smaller manufacturing facilities are located in Marseille, Brussels,
Amsterdam, and Krakow. WAN traffic follows a typical hub-and-spoke pattern, as
diagrammed in Figure 7.9.
Brussels
Amsterdam
512Kbs
512Kbs
Leuven
7
128Kbs
Marseille
256Kbs
Krakow
FIGURE 7.9 CompanyA WAN diagram.
CompanyA decided to deploy Windows Server 2008 R2 to all its branch locations and allocated several domain controllers for each location. Sites in AD DS were designated for each
major location within the company and given names to match their physical location.
Site links were created to correspond with the WAN link locations, and their replication
schedules were closely tied with WAN utilization levels on the links themselves. The result
was a Windows Server 2008 R2 AD DS site diagram that looks similar to Figure 7.10.