04 CHAPTER 1 Designing A TCP and IP Network

C H A P T E R 1
Designing a TCP/IP
Network
The TCP/IP protocol suite defines industry standard networking protocols for data networks, including the
Internet. Determining the best design and implementation of your TCP/IP network ensures optimal reliability,
availability, scalability, security, and performance for your enterprise. You can also start to explore the next
generation of the Internet layer protocol of the TCP/IP protocol suite — IP version 6 (IPv6) — by introducing
Microsoft® Windows® Server 2003 IPv6 into part of your IPv4 network.
In This Chapter
Overview of Designing a TCP/IP Network.............................................................. ...4
Planning the IP-Based Infrastructure................................................ .......................7
Developing Routing Strategies................................................................. .............10
Designing an IP Addressing Scheme........................................ .............................14
Planning an IP Configuration Strategy......................................................... ..........26
Planning Security.......................................................................... ........................28
Improving Availability.................................................................................... ........32
Planning IP Multicasting.............................................................. ..........................35
Introducing IPv6 on Your Network......................................................................... .42
Testing Your Design............................................................................ ...................64
Additional Resources................................................................................ .............67
Related Information
• For more information about IP configuration strategies using Dynamic Host Configuration
Protocol (DHCP), see “Deploying DHCP” in this book.
• For more information about using Domain Name System (DNS) for name resolution, see
“Deploying DNS” in this book.
• For more information about using Windows Internet Name Service (WINS) for name resolution
in networks that support clients running Microsoft® Windows NT®, see “DeployingWINS” in
this book.
4 Chapter 1 Designing a TCP/IP Network
Overview of Designing a TCP/IP

Network
Designing your IP deployment includes deciding how you want to implement IP in a new environment, or — for
most organizations — examining your existing infrastructure and deciding what to change. Windows
Server 2003 TCP/IP, the most widely used networking protocol, can connect different types of systems, provide
a framework for client/server applications, and give users access to the Internet. TCP/IP is included in the
Microsoft® Windows® Server 2003, Standard Edition; Windows® Server 2003, Enterprise Edition; Windows®
Server 2003, Datacenter Edition; and Windows® Server 2003, Web Edition operating systems.
Before you start the TCP/IP design process, inventory your hardware and software and create or update a map of
your network topology. Preparing an inventory and network map can save time and help you focus on the design
decisions you want to address. After you review your existing network, you might upgrade several servers to
Windows Server 2003 in order to take advantage of end-to-end support for TCP/IP, or you might decide to
redesign your entire network to improve its efficiency and prepare for the future of IP networking. Determine
which design tasks are relevant to your environment, and then decide what changes you want to make to your
network. For more information about creating a hardware and software inventory and a network topology map,
see “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit.
To start the TCP/IP design process, you must make a number of design decisions about your network
infrastructure. For enterprise-wide scalability, you might decide to plan your IP infrastructure based on a
hierarchical network design model. You must also choose between hardware and software-based routers, and
decide where to use static routing or dynamic routing protocols. You must carefully design a structured model
for IP address assignment that fits your current networking environment and that accommodates expected
growth. Your model can use either public or private addresses, or you can use a combination of public and
private addresses.
In addition, consider security issues for an IP network, including where best to use Internet Protocol security
(IPSec) and which options are appropriate for securing your perimeter network. For higher availability and load
balancing, you can include redundancy in your network design. Decide whether you need to use technology
enhancements such as IP multicast to optimize server workload and network bandwidth. You might start
deploying IPv6 on certain network servers or clients, and, if so, decide how you want to implement IPv6/IPv4
coexistence.
After you develop your network design, you can use the remaining chapters in this book as a guide for
deploying core features, such as DHCP, DNS, and WINS, as well as optional technologies, such as support for
mobile or home users, connecting remote sites, or deploying wireless solutions.
Developing Routing Strategies 5
Process for Designing a TCP/IP Network

Figure 1.1 shows the design stages involved in deploying TCP/IP. Although the figure lists the stages
sequentially, you must consider each topic in relation to the others rather than as a linear step-by-step process.
Figure 1.1 Designing a TCP/IP Network
Windows Server 2003 TCP/IP Background

Windows Server 2003 TCP/IP enables enterprise networking and connectivity on computers running Windows
Server 2003, Microsoft® Windows® XP, Windows® 2000, Windows NT®, Windows® Millennium Edition,
Windows® 98, and Windows® 95.
Benefits of Windows Server 2003 TCP/IP

Using TCP/IP in a Windows Server 2003 configuration offers the following advantages:
• Enables the most widely used network protocol. Windows Server 2003 TCP/IP is a complete,
standards-based implementation of the most widely accepted networking protocol in the world.
IP is routable, scalable, and efficient. IP forms the basis for the Internet, and it is also used as
the primary network technology on most major enterprise networks in production today. You
can configure computers running Windows Server 2003 with TCP/IP to perform nearly any role
that a networked computer requires.
• Connects dissimilar systems. Although all modern networking operating systems offer TCP/IP
support, Windows Server 2003 TCP/IP provides the best platform for connecting Windows–
based systems to earlier Windows systems and to non-Windows systems. Most standard
connectivity utilities are available in Windows Server 2003 TCP/IP, including the File Transfer
Protocol (FTP) program, the Line Printer (LPR) program, and Telnet, a terminal emulation
protocol.
• Provides client/server framework. Windows Server 2003 TCP/IP provides a cross-platform
client/server framework that is robust, scalable, and secure. Windows Server 2003 TCP/IP
offers the Windows Sockets programming interface, which is ideal for developing client/server
applications that can run on Windows Sockets−compliant TCP/IP protocol implementations
from other vendors.
• Provides access to the Internet. Windows Server 2003 TCP/IP can provide users with a
method of gaining access to the Internet. A computer running Windows Server 2003 can be
configured to serve as an Internet Web site, it can function in a variety of other roles as an
Internet client or server, and it can use nearly all of the Internet-related software available today.
Planning the IP-Based

Infrastructure
To create or expand an enterprise network, you can choose from many design models, including a network
infrastructure model based on the three-tier design model. This model, a hierarchical network design model
described by Cisco Systems, Inc. and other networking vendors, is widely used as a reference in the design of
enterprise networks.
Figure 1.2 shows the tasks involved in creating a three-tier TCP/IP infrastructure.
Figure 1.2 Planning the IP-Based Infrastructure
The modular nature of a hierarchical model such as the three-tier model can simplify deployment, capacity
planning, and troubleshooting in a large internetwork. In this design model, the tiers represent the logical layers
of functionality within the network. In some cases, network devices serve only one function; in other cases, the
same device may function within two or more tiers.
The three tiers of this hierarchical model are referred to as the core, distribution, and access tiers. Figure 1.3
illustrates the relationship between network devices operating within each tier.
Figure 1.3 Three-Tier Network Design Model
Designing the Access Tier

The access tier is the layer in which users connect to the rest of the network, including individual workstations
and workgroup servers. The access tier usually includes a relatively large number of low- to medium-speed
access ports, whereas the distribution and core tiers usually contain fewer, but higher-speed network ports.
Design the access tier with efficiency and economy in mind, and balance the number and types of access ports
to keep the volume of access requests within the capacity of the higher layers.
Designing the Distribution Tier

The distribution tier distributes network traffic between related access layers, and separates the locally destined
traffic from the network traffic destined for other tiers through the core.
Network security and access control policies are often implemented within this tier. Network devices in this
layer can incorporate technologies such as firewalls and address translators.
The distribution tier is often the layer in which you define subnets; through the definition of subnets,
distribution devices often function as routers. Decisions about routing methods and routing protocols affect the
scalability and performance of the network in this tier.
A server network in the distribution layer might house critical network services and centralized application
servers. Computers running Windows Server 2003 can be used there to run the Active Directory® directory
service, DNS, DHCP, and other core infrastructure services.
Designing the Core Tier

The core tier facilitates the efficient transfer of data between interconnected distribution tiers. The core tier
typically functions as the high-speed backbone of the enterprise network. This tier can include one or more
building-wide or campus-wide backbone local area networks (LANs), metropolitan area network (MAN)
backbones, and high-speed regional wide area network (WAN) backbones.
The primary design goal for the core is reliable, high-speed network performance. As a general rule, locate any
feature that might affect the reliability or performance of this tier in an access or distribution tier instead.
Select highly reliable network equipment for the core tier, and design a fault-tolerant core system whenever
possible. Many products meet these criteria, and most major network vendors offer complete solutions to meet
the requirements of the core tier.
For more information about designing a three-tier network model, see “Additional Resources” later in this
chapter.
Developing Routing Strategies

After planning your network infrastructure based on your design model, plan how to implement routing.
Figure 1.4 shows the tasks involved in developing a unicast routing strategy. For information about IP multicast
routing, see “Planning IP Multicasting” later in this chapter.
Figure 1.4 Developing a Routing Strategy
To plan an effective routing solution for your environment, you must understand the differences between
hardware routers and software routers; static routing and dynamic routing; and distance vector routing protocols
and link state routing protocols.
Choosing Hardware or Software Routing

A router is a device that holds information about the state of its own network interfaces and contains a list of
possible sources and destinations for network traffic. The router directs incoming and outgoing packets based on
that information. By projecting network traffic and routing needs based on the number and types of hardware
devices and applications used in your environment, you can better decide whether to use a dedicated hardware
router, a software-based router, or a combination of both. Generally, dedicated hardware routers handle heavier
routing demands best, and less expensive software-based routers are sufficient to handle lighter routing loads.
A software-based routing solution, such as the Windows Server 2003 Routing and Remote Access service, can
be ideal on a small, segmented network with relatively light traffic between subnets. Conversely, enterprise
network environments that have a large number of network segments and a wide range of performance
requirements might need a variety of hardware-based routers to perform different roles throughout the network.
Choosing Static or Dynamic Routing

Routing can be either static or dynamic, depending on how routing information is generated and maintained:
• In static routing, routing information is entered manually by an administrator and remains
constant throughout the router’s operation.
• In dynamic routing, a router is configured to automatically generate routing information and
share the information with neighboring routers.
You must decide where best to implement each type of routing.
Static Routing
In static routing, a network administrator enters static routes in the routing table manually by indicating:
• The network ID, consisting of a destination IP address and a subnet mask.
• The IP address of a neighboring router (the next hop).
• The router interface through which to forward the packets to the destination.
Static routing has significant drawbacks. Because a network administrator defines a static route, errors are more
likely than with a dynamically assigned route. A simple typographical error can create chaos on the network. An
even greater problem is the inability of a static route to adapt to topology changes. When the topology changes,
the administrator might have to make changes to the routing tables on every static router. This does not scale
well on a large internetwork.
However, static routing can be effective when used in combination with dynamic routing. Instead of
using static routing exclusively, you can use a static route as the redundant backup for a
dynamically configured route. In addition, you might use dynamic routing for most paths but
configure a few static paths where you want the network traffic to follow a particular route. For
example, you might configure routers to force traffic over a given path to a high-bandwidth link.
Dynamic Routing Protocols

Conceptually, the dynamic routing method has two parts: the routing protocol that is used between neighboring
routers to convey information about their network environment, and the routing algorithm that determines paths
through that network. The protocol defines the method used to share the information externally, whereas the
algorithm is the method used to process the information internally.
The routing tables on dynamic routers are updated automatically based on the exchange of routing information
with other routers. The most common dynamic routing protocols are:
• Distance vector routing protocols
• Link state routing protocols
Understanding how these protocols work enables you to choose the type of dynamic routing that best suits your
network needs.
Distance Vector Routing Protocols

A distance vector routing protocol advertises the number of hops to a network destination (the distance) and the
direction in which a packet can reach a network destination (the vector). The distance vector algorithm, also
known as the Bellman-Ford algorithm, enables a router to pass route updates to its neighbors at regularly
scheduled intervals. Each neighbor then adds its own distance value and forwards the routing information on to
its immediate neighbors. The result of this process is a table containing the cumulative distance to each network
destination.
Distance vector routing protocols, the earliest dynamic routing protocols, are an improvement over static
routing, but have some limitations. When the topology of the internetwork changes, distance vector routing
protocols can take several minutes to detect the change and make the appropriate corrections.
One advantage of distance vector routing protocols is simplicity. Distance vector routing protocols are easy to
configure and administer. They are well suited for small networks with relatively low performance
requirements.
Most distance vector routing protocols use a hop count as a routing metric. A routing metric is a number
associated with a route that a router uses to select the best of several matching routes in the IP routing table. The
hop count is the number of routers that a packet must cross to reach a destination.
Routing Information Protocol (RIP) is the best known and most widely used of the distance vector routing
protocols. RIP version 1 (RIP v1), which is now outmoded, was the first routing protocol accepted as a standard
for TCP/IP. RIP version 2 (RIP v2) provides authentication support, multicast announcing, and better support for
classless networks. The Windows Server 2003 Routing and Remote Access service supports both RIP v1 and
RIP v2 (for IPv4 only).
Using RIP, the maximum hop count from the first router to the destination is 15. Any destination greater than 15
hops away is considered unreachable. This limits the diameter of a RIP internetwork to 15. However, if you
place your routers in a hierarchical structure, 15 hops can cover a large number of destinations.
Link State Routing Protocols

Link state routing protocols address some of the limitations of distance vector routing protocols. For example,
link state routing protocols provide faster convergence than do distance vector routing protocols. Convergence is
the process by which routers update routing tables after a change in network topology — the change is
replicated to all routers that need to know about it. Although link state routing protocols are more reliable and
require less bandwidth than do distance vector routing protocols, they are also more complex, more memory-
intensive, and place a greater load on the CPU.
Unlike distance vector routing protocols, which broadcast updates to all routers at regularly scheduled intervals,
link state routing protocols provide updates only when a network link changes state. When such an event occurs,
a notification in the form of a link state advertisement is sent throughout the network.
The Windows Server 2003 Routing and Remote Access service supports the Open Shortest Path First (OSPF)
protocol, the best known and most widely used link state routing protocol. OSPF is an open standard developed
by the Internet Engineering Task Force (IETF) as an alternative to RIP. OSPF compiles a complete topological
database of the internetwork. The shortest path first (SPF) algorithm, also known as the Djikstra algorithm, is
used to compute the least-cost path to each destination. Whereas RIP calculates cost on the basis of hop count
only, OSPF can calculate cost on the basis of metrics such as link speed and reliability in addition to hop count.
Unlike RIP, OSPF can support an internetwork diameter of 65,535 (assuming that each link is assigned a cost of
1). OSPF transmits multicast frames, reducing CPU usage on a LAN. You can hierarchically subdivide OSPF
networks into areas, reducing router memory overhead and CPU overhead.
Like RIP v2, OSPF supports variable length subnet masks (VLSM) and noncontiguous subnets. For information
about variable length subnet masks and noncontiguous subnets, see “Designing a Structured Address
Assignment Model” later in this chapter.
Selecting the Appropriate Routing Protocol

Select a routing protocol based on the following considerations:
• For a small, simple network that is not expected to grow, use a simpler distance vector routing
protocol like RIP v2. For a large, complex internetwork, use a newer, more sophisticated link
state routing protocol like OSPF.
• Use RIP v2 or OSPF if you need to support variable length subnet masks. Although the
outdated RIP v1 is still widely used in private networks, it does not support VLSM and thus is
not well suited for enterprise networks. For more information about VLSM, see “Planning
Variable Length Subnet Masks” later in this chapter.
Designing an IP Addressing
Scheme
Before assigning addresses, design an IP addressing scheme that meets the requirements of your networking
infrastructure. Figure 1.5 shows the tasks involved in designing your IP addressing system, including planning
your address assignment model, address allocation, and public or private addressing. Most organizations choose
to use classless IP addressing, classless IP routing protocols, and route summarization.
Figure 1.5 Designing an IP Addressing Scheme
For information about IP multicast addressing, see “Planning IP Multicasting” later in this chapter.
Creating a Structured Address Assignment

Model
You can ease the burden of enterprise internetwork administration by designing a structured address assignment
model. A structured address assignment model makes troubleshooting easier and more systematic and helps you
interpret network maps and locate specific devices. It also simplifies the use of network management software.
For enterprise scalability, assign address blocks hierarchically.
The structured address assignment model reflects more than just hierarchical concerns. To maximize network
stability and scalability, assign a block of addresses based on a physical network rather than on membership
within a department or team, to avoid complications when you move a workstation to a new location. For more
information about address allocation as it relates to your IP addressing scheme, see “Choosing an Address
Allocation Method” later in this chapter.
As a general rule, assign static addresses to routers and servers, and assign dynamic addresses to workstations.
This scheme minimizes manual addressing, reducing the chances of address duplication and stabilizing the
network’s addressing structure. You can assign meaningful numbers when using static addresses; for example,
reserve host addresses in the low or high portion of the range, and manually assign these addresses to routers or
servers.
To design a structured model for assigning addresses:
• Plan classless IP addressing.
• Plan classless routing.
• Use route summarization.
• Plan variable length subnet masks (VLSM).
• Plan supernetting and classless interdomain routing (CIDR).
Planning Classless IP Addressing

Classless IP addressing makes traditional classful IP addressing methods — restricted to the standard IP address
classes in their default formats — out of date for enterprise networks. Of the five address classes, Class A, B,
and C addresses, collectively known as IPv4 unicast addresses, are assigned to specific devices on an IPv4
network. Class D addresses, known as multicast addresses, are used for IP multicasting (simultaneously sending
a message to more than one network destination). Class E addresses are reserved for experimental purposes.
To be able to use subnetting or supernetting, you must first understand the default formats of the unicast
addresses. Unicast addresses have the following formats:
• All 32-bit IPv4 addresses contain four octets of 8 bits each, often represented as four decimal
numbers separated by dots (known as dotted decimal notation).
• In Class A addresses, the first byte, or octet, represents the network ID, and the three remaining
bytes are used for node addresses.
• In Class B addresses, the first 2 bytes represent the network ID, and the last 2 bytes are used for
nodes.
• In Class C addresses, the first 3 bytes are used for the network ID, and the final byte is used for
nodes.
Without some means of subdividing class-designated networks, all available IP addresses would have been
depleted long ago. Classless IP addressing, which allows subnetting, was developed to handle this problem.
Determining the Number of Subnets and Hosts

To better use the address space, instead of using the unicast addresses in their default formats, you can use
subnet addressing, which lets you “borrow” additional bits from the host part of the address to divide the
network into subnets. In subnetting, the subnet mask consists of the octets assigned to the network plus the bits
added for the subnet. You can use subnet mask notation to indicate these leftmost contiguous bits.
For example, for a Class B address, which has a default subnet mask of 255.255.0.0, you might allocate an
additional 8 bits for subnets. That is, for a Class B address such as 131.107.65.37, you can use the following
subnet mask, shown in both decimal and binary notation.
Subnet Mask in Decimal Notation Subnet Mask in Binary Notation
255.255.255.0 11111111 11111111 11111111 00000000
By using 8 host bits for subnetting, you obtain 256 (that is, 28) subnetted network IDs (subnets), supporting as
many as 254 hosts per subnet. The number of hosts per subnet is 254 because 8 bits (28 minus 2) are reserved for
the host ID. You subtract 2 because subnetting rules exclude the host IDs consisting of all ones or all zeros.
An alternative to subnet mask notation is the network prefix length notation. A network prefix is shorthand for a
subnet mask, expressing the number of high-order bits that constitute the subnetted network ID portion of the
address in the format <IP address>/<# of bits>, where # of bits defines the network/subnet part of the IP address,
and the remaining bits represent the host ID portion of the address.
The following is the network prefix length notation for the Class B address in the previous example:
131.107.65.37/24
The bit notation “/24” refers to the number of high-order bits set to 1 in the binary notation for the subnet mask,
leaving 8 bits for hosts (the eight bits set to 0).
Note
IPv6 supports only network prefix length notation. It does not support
dotted decimal subnet masks. For more information about IPv6, see
“Introducing IPv6 on Your Network” later in this chapter.
By contrast, if you anticipate needing only 32 subnets rather than 256, each of the 32 subnets can support as
many as 2,046 hosts (211 minus 2). That subnet mask has the following decimal and binary notations.
Subnet Mask in Decimal Notation Subnet Mask in Binary Notation
255.255.248.0 11111111 11111111 11111000 00000000
The following network prefix length notation indicates the 21 bits needed to create as many as 32 subnets:
131.107.65.37/21.
Again, “/21” indicates the number of high-order bits set to 1 in binary notation, leaving 11 bits (the 11 zeros) for
the host ID portion of the address.
To determine the appropriate number of subnets versus hosts for your organization’s network, consider the
following:
• More subnets. Allocating more host bits for subnetting supports more subnets but fewer hosts
per subnet.
• More hosts. Allocating fewer host bits for subnetting supports more hosts per subnet, but limits
the growth in the number of subnets.
For an introduction to TCP/IP, including information about subnetting, see the Networking Guide of the
Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
http://www.microsoft.com/reskit).
Planning Classless Routing

Organizations today typically implement classless routing solutions. With classful routing protocols, IP hosts
and routers recognize only the network address designated by the standard address classes. An IP host device or
a router using a classful protocol such as RIP v1 cannot recognize subnets.
Classless routing protocols extend the standard Class A, B, or C IP addressing scheme by using a subnet mask
or mask length to indicate how routers must interpret an IP network ID. Classless routing protocols include the
subnet mask along with the IP address when advertising routing information. Subnet masks representing the
network ID are not restricted to those defined by the address classes, but can contain a variable number of high-
order bits. Such subnet mask flexibility enables you to group several networks as a single entry in a routing
table, significantly reducing routing overhead. In addition to RIP v2 and OSPF, described earlier, classless
routing protocols include Border Gateway Protocol version 4 (BGP4) and Intermediate System to Intermediate
System (IS-IS).
If your network contains routers that support only RIP v1 and you want to upgrade from classful to classless
routing, upgrade the RIP v1 routers to support RIP v2 or use another protocol such as OSPF. For example, you
might use VLSM to implement subnets of different sizes or CIDR to implement supernetting. (VLSM and CIDR
are described later in this chapter.)
Planning Classless Noncontiguous Subnets

One reason that classful routing is out of date is that classful routing protocols cannot reliably handle
noncontiguous subnets of a subnetted class-based network ID. As mentioned earlier, classful routing protocols
recognize only those networks indicated by an address class. Because classful protocols do not transmit subnet
mask or prefix length information, noncontiguous subnets, when summarized by a classful routing protocol, can
have the same class-based network ID.
Noncontiguous subnets with classful routing
Noncontiguous subnets occur when another network with a different network ID separates subnets of a classful
network. For example, the two routers in Figure 1.6 separate two subnets that each use the base prefix
10.0.0.0/8, which is a Class A private network. A segment of another class-based network connects the two
routers. (For more information about private addresses, see “Choosing Public or Private Addresses” later in this
chapter.)
Figure 1.6 Classful Routing Not Appropriate for Noncontiguous Subnets
Each router in Figure 1.6 must use a subnet mask to look up a match in the routing table. Because a classful
address, by definition, has only its class-based default subnet mask, the router uses the network mask that
corresponds to the class of the subnet ID when advertising the route for the subnet. With classful routing, each
of the routers in Figure 1.6 summarizes and advertises the class-based network ID of 10.0.0.0/8, resulting in two
routes to 10.0.0.0/8, each of which might have a different metric. Therefore, a packet meant for one subnet
could be incorrectly routed to the other subnet. In the figure, the arrows represent the routes advertised by the
routers.
Noncontiguous subnets with classless routing
Figure 1.7 also shows an unrelated network connecting two noncontiguous subnets. In this example, using
classless routing, the locations on the noncontiguous subnets are unambiguous because the classless protocol
includes a subnet mask when advertising the route. Routers in the intermediate network can distinguish between
the two noncontiguous subnets.
Figure 1.7 Classless Routing Appropriate for Noncontiguous Subnets
Using Route Summarization

With route summarization, or aggregation, in a hierarchical routing infrastructure, one route in a routing table
represents many routes. A routing table entry for the highest level (the network) is also the route used for
subnets and sub-subnets. In contrast, in a flat routing infrastructure, the routing table on every router in the
network contains an entry for each network segment. When you use flat routing, the network IDs have no
network/subnet structure and cannot be summarized. RIP-based Internet Packet Exchange (IPX) internetworks
use flat network addressing and have a flat routing infrastructure.
Using route summarization, you can contain topology changes occurring in one area of the network within that
area. Route summarization simplifies routing tables and reduces the exchange of routing information, but it
requires more planning than does a flat routing infrastructure.
To support route summarization, your IP addressing scheme must meet the following requirements:
• Classless routing protocols (those including subnet mask or prefix length information along
with the IP address) must be used.
• All IP addresses used in route summarization must share identical high-order bits.
• The length of the prefix can be any number of bits up to 32 (for IPv4).
Planning Variable Length Subnet Masks (VLSM)

Variable length subnet masks (VLSMs) allow you to use different prefix lengths at different locations so that
subnets of different sizes can coexist on the same network. Instead of using one subnet mask throughout the
network, you apply several masks to the same address space, producing subnets of different sizes. For example,
given the Class B network ID of 131.107.0.0, you can configure one subnet with as many as 32,766 hosts,
15 subnets with as many as 2,046 hosts, and 8 subnets with as many as 254 hosts.
Tip
When using VLSM, do not accidentally overlap blocks of addresses. If
possible, start with equal-size subnets and then subdivide them.
VLSM also can be used when a point-to-point WAN link connects two routers. One way to handle such a WAN
link is to create a small subnet consisting of only two addresses. Without VLSM, you might divide a Class C
network ID into an equal number of two-address subnets. If only one WAN link is in use, all the subnets but one
serve no purpose, wasting 252 addresses.
Alternatively, you can divide the Class C network into 16 workgroup subnets of 14 nodes each by using a prefix
length of 28 bits (or, in subnet mask terms, 255.255.255.240). By using VLSM, you can then subdivide one of
those 16 subnets into 8 smaller subnets, each supporting only 2 nodes. You can use one of the 8 subnets for your
existing WAN link and reserve the remaining 7 subnets for similar links that you might need in the future. To
accomplish this act of sub-subnetting by using VLSM, use a prefix length of 30 bits (or, in subnet mask terms,
255.255.255.252).
Figure 1.8 shows variable length subnetting for two-host WAN subnets.
Figure 1.8 Variable Length Subnetting of 131.107.106.0
If your network includes numerous WAN links, each with its own subnet, this approach can require significant
administrative overhead. If you do not use route summarization, each subnet requires another entry in the
routing table, increasing the overhead of the routing process.
Some routers support unnumbered connections; a link with unnumbered connections does not require its own
subnet.
Planning Supernetting and Classless Interdomain Routing

(CIDR)
Similar to the way that subnetting allows you to divide class-based networks into smaller subnets by
“borrowing” bits from the host part of the address, supernetting allows you to combine contiguous subnets into
larger supernets by “borrowing” bits from the network part of the address. For example, rather than allocate a
Class B network ID to an organization that has 2,000 hosts, the Internet Assigned Numbers Authority (IANA)
might allocate a range of eight Class C network IDs. Each Class C network ID accommodates 254 hosts, for a
total of 2,032 host IDs.
Although this technique helps conserve Class B network IDs, it creates a new problem. Using conventional
routing techniques, the routers on the Internet must, in this example, have eight Class C network ID entries in
their routing tables to route IP packets to the organization. To prevent Internet routers from becoming
overwhelmed with routes, a technique called Classless Interdomain Routing (CIDR), which the Internet uses to
summarize routes, collapses multiple network ID entries into a single entry. In this example, CIDR collapses the
network IDs that correspond to the eight Class C network IDs allocated to that organization into one entry.
A supernetted subnet mask conveys the starting network ID and the number of Class C network IDs allocated.
The following tables demonstrate how eight Class C network IDs are allocated. Table 1.1 indicates the
contiguous allocation of eight Class C network IDs, starting with network ID 220.78.168.0. Note that the first
21 bits (underlined) are the same for the starting network ID and the ending network ID. The last 3 bits of the
third octet, which are borrowed from the network ID, range from 000 through 111. In decimal notation, the
range is 0 through 7, or 8 total contiguous subnets, which are combined into one supernet.
Table 1.1 Supernetted Block of Addresses
Network ID Subnet Mask (Binary)
Starting Network ID 220.78.168.0 11011100 01001110 10101000 00000000
Ending Network ID 220.78.175.0 11011100 01001110 10101111 00000000
A block of supernetted addresses, such as those in Table 1.2, is known as a CIDR block. Table 1.2 indicates the
single CIDR entry that appears in the routing table. This entry represents all eight Class C network IDs that are
allocated to the example organization.
Table 1.2 CIDR Routing Table Entry
Network ID Subnet Mask Subnet Mask (Binary)
220.78.168.0 255.255.248.0 11111111 11111111 11111000 0000000
In network prefix length notation, the CIDR block is 220.78.168.0/21.

RIP v2, OSPF, and BGP4, which can exchange routing information in the form of [Network ID, Network Mask]
pairs, support CIDR.
Choosing an Address Allocation Method

Choose an address allocation method that best fits your structured address model. Addressing by topology is
recommended. However, you can choose one or more of the following methods:
• Random address allocation. Under a random addressing structure, you can assign blocks of
addresses randomly. Random address allocation might be the most frequently used address
allocation method, but it is the least desirable. For a small network where no significant growth
is anticipated, this approach might be appropriate. However, if the network does grow, random
address allocation can cause extra work for network administrators. Summarizing the random
collection of routes might be difficult or impossible. This method can cause stability problems,
with numerous routes being advertised to the core tier.
• Addressing by organization chart. To base your address structure on your organization chart,
you create subnets based on a pool of addresses preassigned to a department or team. If, for
example, you designate the Sales department as 10.2.0.0/16, the address 10.2.1.0/24 might be
the subnet for the sales team at one site and 10.2.2.0/24 might be the subnet for the sales team at
another site. To the extent that contiguous subnets remain unassigned, this address allocation
method offers limited possibilities for route summarization, but, as a rule, this kind of
addressing scheme does not scale well.
• Addressing by geographical region. When you base your address structure on location, a
greater degree of summarization is possible. However, as the internetwork of a geographically
diverse organization continues to grow, fewer routes are available for summarization.
• Addressing by topology. By basing your address structure on topology, you can ensure that
summarization takes place and that an internetwork remains scalable and stable. Addressing by
topology makes the addressing structure router-centric, enhancing efficiency.
Choosing Public or Private Addresses

If you use a direct (routed) connection to the Internet, you must use public addresses. If you use an indirect
connection such as a proxy server or Network Address Translator (NAT), use private addresses. If your
organization is not connected to the Internet, use private addresses (rather than “unauthorized” addresses) so that
if you later connect to the Internet using an indirect connection, you do not need to change addresses already in
use.
If you connect to the Internet by using an Internet service provider (ISP), the ISP might provide only private
addresses. The ISP itself uses public addresses to connect to the Internet.
Public Addresses
IANA assigns public addresses and guarantees them to be globally unique on the Internet. In addition, routes are
programmed into the routers on the Internet so that traffic can reach those assigned public addresses. That is
why public addresses can be reached on the Internet.
Private Addresses
Private addresses are a predefined set of IPv4 addresses that the designers of the Internet provided for those
hosts within an organization that do not require direct access to the Internet. These addresses do not duplicate
already assigned public addresses. RFC 1918, “Address Allocation for Private Internets,” defines the following
three private address blocks:
• 10.0.0.0/8. The 10.0.0.0/8 private network is a Class A network ID that supports the following
range of valid IP addresses: 10.0.0.1 through 10.255.255.254. The 10.0.0.0/8 private network
has 24 host bits that a private organization can use for any subnetting scheme within the
organization.
• 172.16.0.0/12. The 172.16.0.0/12 private network can be interpreted either as a block of 16
Class B network IDs or as a 20-bit assignable address space (20 host bits) that can be used for
any subnetting scheme within the private organization. The 172.16.0.0/12 private network
supports the following range of valid IP addresses: 172.16.0.1 through 172.31.255.254.
• 192.168.0.0/16. The 192.168.0.0/16 private network can be interpreted either as a block of 256
Class C network IDs or as a 16-bit assignable address space (16 host bits) that can be used for
any subnetting scheme within the private organization. The 192.168.0.0/16 private network
supports the following range of valid IP addresses: 192.168.0.1 through 192.168.255.254.
Because IANA never assigns IP addresses in the private address space as public addresses, routes for private
addresses never exist on the Internet routers. Any number of organizations can repeatedly use the private
address space, which helps to prevent the depletion of public addresses.
Private addresses cannot be reached on the Internet. Therefore, Internet traffic from a host that has a private
address must either send its requests to an application layer gateway (such as a proxy server), which has a valid
public address, or have its private address translated into a valid public address by a NAT before it is sent over
the Internet.
For an introduction to TCP/IP and more information about public and private addresses, see the Networking
Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
Unauthorized Addresses
Network administrators of private networks who have no plans to connect to the Internet can choose any IP
addresses they want, even public addresses that IANA has assigned to other organizations. Such potentially
duplicate addresses are known as unauthorized (or illegal) addresses. Later, if the organization decides to
connect directly to the Internet after all, its current addressing scheme might include addresses that IANA has
assigned to other organizations. You cannot connect to the Internet by using unauthorized addresses.
Do not use unauthorized addresses if even the slightest possibility exists of ever establishing a connection
between your network and the Internet. On some future date, discovering that you need to quickly replace the IP
addresses of all the nodes on a large private network can require considerable time and interrupt network
operation.
Network Address Translation

Network address translation, defined in RFC 3022, is the translation process performed by an IP router
functioning as a network address translator (NAT). A NAT translates IP addresses from private network
addresses used inside an organization to public addresses used outside the organization. Typically, a NAT-
enabled router connects an internal corporate network with the Internet and builds a table that maps the
connections between hosts inside the network and hosts outside on the Internet.
You can use NAT to map multiple internal private addresses to a single external public IP address. For example,
a small business might obtain an ISP−allocated public IP address for each computer on its network. By using
NAT, however, the business could use private addressing internally and have NAT map its private addresses to
one or more public IP addresses that the ISP allocates.
NAT makes it more difficult for external users to attack systems on a private network. NAT also allows several
nodes on the private network, each with its own private address, to share a smaller number of scarcer public
addresses to access the Internet. However, although NAT allows you to reuse the private address space, it does
not support standards-based network layer security or the correct mapping of all higher layer protocols. One
purpose for the large number of addresses made available with the introduction of IPv6 is to make address
conservation techniques such as NAT unnecessary.
Windows Server 2003 also supports IPSec NAT traversal (NAT-T), which allows nodes located behind a NAT
(that is, they use private addresses) to use Encapsulating Security Payload (ESP) to protect traffic. This
capability allows the creation of Layer Two Tunneling Protocol with IPSec (L2TP/IPSec) connections from
remote access clients and routers located behind NATs.
For more information about unicast IP routing, including technical information about the NAT routing protocol
component of the Routing and Remote Access service, see the Internetworking Guide of the Windows
Server 2003 Resource Kit (or see the Internetworking Guide on the Web at http://www.microsoft.com/reskit).
Planning an IP Configuration
Strategy
Every computer on an IP network must have a unique IP address. As noted earlier, using static addressing for
clients is time-consuming and prone to error. To provide an alternative for IPv4, the IETF developed the
Dynamic Host Configuration Protocol (DHCP), based on the earlier bootstrap protocol (BOOTP) standard.
Figure 1.9 shows the stage in the TCP/IP design process during which you decide what to use for IP
configuration. Most organizations choose to use DHCP for IPv4.
Figure 1.9 Planning an IP Configuration Strategy
Although BOOTP and DHCP hosts can interoperate, DHCP is easier to configure. BOOTP requires maintenance
by a network administrator, whereas DHCP requires minimal maintenance after the initial installation and
configuration.
The DHCP standard, defined in RFC 2131, defines a DHCP server as any computer running the DHCP service.
Compared with static addressing, DHCP simplifies IP address management because the DHCP server
automatically allocates IP addresses and related TCP/IP configuration settings to DHCP-enabled clients on the
network. This is especially useful on a network with frequent configuration changes — for example, in an
organization that has a large number of mobile users.
The DHCP server dynamically assigns specific addresses from a manually designated range of addresses called
a scope. By using scopes, you can dynamically assign addresses to clients on the network no matter where the
clients are located or how often they move.
DHCP Integration with DNS and WINS

The DHCP implementation in Windows Server 2003 is closely linked to name resolution services such as the
Domain Name System (DNS) service and the Windows Internet Name Service (WINS). Network administrators
benefit from combining all three when planning a deployment.
If you use DHCP servers for Windows-based network clients, you must use a name resolution service. In
addition to name resolution, Windows Server 2003 networks use DNS to support Active Directory. Domain-
based networks supporting clients running Windows NT version 4.0 or earlier or NetBIOS applications must use
WINS servers. Networks supporting a combination of clients running Windows XP, Windows 2000, Windows
Server 2003, and Windows NT 4.0 must implement both WINS and DNS.
DHCP, APIPA, and IP Address Allocation

DHCP clients receive IP addresses as follows:
• Dynamic allocation — from DHCP server. After you configure DHCP, the DHCP server
automatically assigns an IP address from a specified scope to a client for a finite period of time
called a lease. Most clients receive a dynamic IP address.
• Static allocation — from DHCP server. For a specific computer (such as a DHCP, DNS, or
WINS server, or a print server, firewall, or router), you can manually configure the TCP/IP
properties, including the IP address, the DNS and WINS parameters, and default gateway
information. For the static clients to be on the same subnet as other, dynamically allocated
computers, the static IP addresses must be within the scope or subnet defined for dynamic
address allocation. You can use the DHCP snap-in to set an exclusion range to prevent the
DHCP server from dynamically allocating the static IP address.
• Client reservation — from DHCP server. By using the DHCP snap-in, you can also reserve a
specific IP address for permanent use by a given DHCP client.
• Automatic allocation — APIPA. In the absence of a DHCP server, Automatic Private IP

Addressing (APIPA) lets a workstation configure itself with an address in the range from
169.254.0.1 to 169.254.255.254. Computers using APIPA addresses can communicate only with
other computers that are also using APIPA addresses within a single subnet. In this case, a
computer has an IP address but cannot connect outside the subnet. APIPA regularly checks for
the presence of a DHCP server; if it detects one, it yields to the DHCP service, which then
assigns a dynamic address to replace the APIPA address. APIPA is designed primarily for
simple networks with only one subnet, such as small or home-based networks. On a larger
network, APIPA can be useful for identifying problems with DHCP: when a client uses an
APIPA address, this indicates that a DHCP server has not been found.
• Alternate configuration — user configured. In the absence of a DHCP server, alternate
configuration lets a computer use an IP address configured manually by the user. Alternate
configuration is designed for a computer that is used on more than one network, such as a
laptop used both at the office and at home. The user can specify an IP address on the computer’s
TCP/IP properties Alternate Configuration tab if at least one of the networks (for example, the
home office) does not have a DHCP server and APIPA addressing is not wanted. If alternate
configuration is not configured and no DHCP server is found, TCP/IP uses APIPA by default.
For more information about developing a DHCP strategy, see “Deploying DHCP” in this book.
Planning Security
IP does not have a default security mechanism. Without security, both public and private IP networks are
susceptible to unauthorized monitoring and access. To prevent these types of security breach, develop a security
strategy for your IP deployment in tandem with your overall network security plan.
Ways that you can enhance security when deploying IP include:
• Securing IP packets. Provide end-to-end security by securing IP packets, which requires that
you not use address translation (unless both peers support IPSec NAT-T and use ESP to protect
traffic). IPSec is the most efficient way to provide a secure data stream.
• Deploying a perimeter network. Use a perimeter network to help secure your internal network
from intrusion. Several options are available for doing this.
Figure 1.10 shows the tasks involved in incorporating IPSec and a perimeter network in your IP security plan.
Figure 1.10 Planning IP Security
Using IPSec
Effective integration with IPSec is becoming increasingly important to the secure deployment of IP in an
enterprise internetwork. IPSec is a framework of open standards for ensuring private, secure communications
over IP networks through the use of cryptographic security services. The implementation of IPSec that runs on
Windows Server 2003, Windows XP, and Windows 2000 is based on standards developed by the IETF IPSec
working group.
IPSec provides a comprehensive technology for securing networks. However, the larger your organization, the
more planning and engineering are required to implement IPSec. Assess the relative importance of your
information resources — domain controllers, mail servers, and financial servers may rank high among the
resources you want to protect. Include confidentiality considerations in your assessment. For example, many
organizations might target Human Resources information for IPSec protection. After identifying the critical
information resources to secure, configure IPSec policies as appropriate on those computers.
Windows Server 2003 uses the IPSec protocol suite to protect data traffic as it crosses a network. Although file
encryption and required passwords protect information stored on network resources, they do not protect
information as it moves across a network.
By implementing IPSec, you can secure the following types of data:
• Data that moves across the part of your intranet that external users do not access.
• Data that moves across the part of your intranet that can be accessed by external users who have
appropriate permissions.
• Data that moves across the Internet.
• Data that moves across an extranet.
IPSec security protects the content of IP packets from both active and passive attacks. In an active attack, a
hacker modifies existing data or adds false data. In a passive attack, an intruder reads data.
IPSec secures communication through the following methods:
• Peer authentication. IPSec verifies the identity of each computer. Each peer sends security
credentials that are verified by the peer at the other end of the connection. Windows
Server 2003 IPSec provides multiple methods of peer authentication.
• Data origin authentication. By incorporating a cryptographic checksum calculated with a
shared secret key with each packet of protected data, IPSec can verify that the packet must have
been sent by a peer that has knowledge of the secret key.
• Confidentiality (data encryption). IPSec offers confidentiality by encrypting data before
transmission, ensuring that the data cannot be read during transmission — even if an attacker
monitors or intercepts the packet. IPSec encryption is applied at the IP network layer, which
makes it transparent to applications that use TCP or User Datagram Protocol (UDP) for network
communication.
• Integrity. IPSec protects data from unauthorized modification in transit, ensuring that the
information received is exactly the same as the information sent.
• Anti-replay. IPSec ensures that any attacker who might intercept data cannot reuse or replay
that data to establish a session or to illegally gain information or access to resources.
Deploying IPSec requires careful planning. For more information about deploying IPSec, see “Deploying
IPSec” in this book. For more technical information about IPSec, see the Networking Guide of the Windows
Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
Using a Perimeter Network

A perimeter network protects your intranet or enterprise LAN from intrusion by controlling access from the
Internet or other large network. The perimeter network (also known as a demilitarized zone or DMZ) is bounded
by firewalls. A firewall is not a single component, but rather a system or combination of systems that enforces a
boundary between two or more networks.
Figure 1.11 shows a perimeter network bounded by firewalls placed between a private network and the Internet
in order to secure the private network.
Figure 1.11 Perimeter Network Securing an Internal Network
Organizations vary in their use of firewalls for providing security. IP packet filtering offers weak security, is
cumbersome to manage, and is easily defeated. Application gateways are more secure than packet filters and
easier to manage because they pertain only to a few specific applications, such as a particular e-mail system.
Circuit gateways are most effective when the user of a network application is of greater concern than the data
being passed by that application. The proxy server — the recommended solution — is a comprehensive security
tool that includes an application gateway, safe access for anonymous users, and other services.
IP packet filtering
You can configure packet filtering, the earliest implementation of firewall
technology, to accept or deny specific types of packets. Packet headers are examined for source and destination
addresses, TCP and UDP port numbers, and other information. Packet filtering is a limited technology that
works best in clear security environments where, for example, everything outside the perimeter network is not
trusted and everything inside is. You cannot use IP packet filtering when IP packet payloads are encrypted
because the port numbers are encrypted and therefore cannot be examined.
In recent years, various vendors have improved on the packet filtering method by adding intelligent decision-
making features to the packet-filtering core, thus creating a new form of packet filtering called stateful protocol
inspection.
Application gateways
Used when the actual content of an application is of greatest concern,
application gateways do not adapt easily to changes in technology. However, unlike IP packet filtering,
application gateways can be used in conjunction with encryption.
Circuit gateways
As tunnels connecting specific processes or systems on each side of a firewall, circuit
gateways are best employed in situations where the person using an application is potentially a greater risk than
the information that the application carries. The circuit gateway differs from a packet filter in its capability for
connecting to an out-of-band application scheme that can add additional information.
Proxy servers
Proxy servers are comprehensive security tools that include firewall and application
gateway functionality to manage Internet traffic to and from a private intranet. Proxy servers also provide
document caching and access control. A proxy server can improve performance by caching and directly
supplying frequently requested data such as a popular Web page. A proxy server also can filter and discard
requests that the owner does not consider appropriate, such as requests for unauthorized access to proprietary
files.
Take advantage of those firewall security features that can help you. Position a perimeter network in your
network topology at a point where all traffic from outside the corporate network must pass through the
perimeter that the external firewall maintains. You can fine-tune access control for the firewall to meet your
needs and can configure firewalls to report all attempts at unauthorized access.
Improving Availability
Availability refers to how much time the network is operational. Planning well for availability improves both
your network’s mean time between failures (MTBF) and its mean time to recovery (MTTR) after a network
failure.
To improve availability in your IP network design, you must know your organization’s availability requirements.
For some organizations, unanticipated down time is simply an irritating inconvenience. In other environments,
unanticipated down time could mean financial disaster, drastic loss of credibility, or, as in health care or law
enforcement, a risk to safety.
Figure 1.12 shows the process for improving availability on your network.
Figure 1.12 Improving Availability
Each method for improving availability places different demands on the design of your network. As the risk of
down time to your operation increases, build more redundancy into your design, both in hardware and routing.
Similarly, as the consequences of failure increase, make your network more resilient by increasing the amount
of stress it can handle before it loses functionality.
Implementing Redundancy
Single points of failure, such as devices, links, and interfaces, can make a network vulnerable. If one such point
fails, it isolates users from services and, in the worst case, causes entire sections of the network to fail. For a
purely hierarchical network — one based on summarization and controlled access between tiers — every device
and link is a point of failure.
Redundancy provides alternative paths around points of failure. In a purely redundant network, each individual
device, link, and interface is dispensable. No single device, link, or interface can isolate users or cause the
network to fail.
In most production environments, neither a purely hierarchical nor a purely redundant network is practical. You
must balance the efficiency of a hierarchical network with the safety net of redundancy.
Implementing Secondary Paths

After deploying multiple devices to eliminate single points of failure, configure secondary paths to take
advantage of the multiple devices. A secondary path, or backup path, consists of the interconnecting devices and
the links between them that duplicate the devices and links in the primary path. For example, you can configure
multiple routers to provide redundancy.
A redundant design uses the secondary path to maintain network connectivity when any of the primary path’s
devices or links fails. Be sure to test any secondary paths on a regular basis. Do not assume that they will work.
If possible, ensure that the switch from the primary path to the secondary path occurs transparently. For mission-
critical applications, automatic failover is mandatory.
Using Load Balancing

In addition to its safety net function, redundancy plays a second valuable role. By properly configuring two or
more paths that connect the same source and destination networks, you can significantly improve throughput by
providing load balancing. Load balancing evenly divides the flow of traffic among parallel links.
Most routing protocols based on open standards support load balancing across paths that the protocol determines
to be equally favorable to the destination. In addition, some vendors’ proprietary routing protocols support load
balancing where the costs of the paths (their relative favorability to the destination in terms of shortest distance,
number of hops, and other criteria) are not considered equal.
For more information about network load balancing, see “Designing Network Load Balancing” in Planning
Server Deployments of this kit.
Planning IP Multicasting
With IP multicasting, one device can send a single data stream that the network replicates only as necessary so
that multiple devices receive the data. Because of the minimal overhead required to create the data stream and
the low overhead on the network, multicast communication is particularly suitable for multiple-user multimedia
applications such as video conferencing, distance learning, and collaborative computing. You can also use
multicast traffic to discover resources on the internetwork and to support datacasting applications such as file
distribution or database synchronization.
Using the IP multicast components of the Windows Server 2003 TCP/IP protocol and the Routing and Remote
Access service, you can send and receive IP multicast traffic from multicast-enabled portions of your intranet or
the Internet and from remote access clients. You can use IP multicast to optimize server loading and network
bandwidth.
Figure 1.13 shows the tasks involved in planning IP multicasting.
Figure 1.13 Planning IP Multicasting
In multicast routing, routers communicate multicast group membership information to each other using
multicast routing protocols, and forward data across the internetwork. Multicast forwarding refers to the process
of forwarding multicast traffic to networks on which other multicast devices are listening. The multicast-capable
portion of the Internet is referred to as the Internet multicast backbone, or MBone.
All computers running Windows Server 2003 can both send and receive IP multicast traffic. Windows
Server 2003 TCP/IP can listen for IPv4 multicast traffic and use a multicast forwarding table to determine where
to forward incoming multicast traffic.
Figure 1.14 shows one common configuration of IP multicast components. For examples of a number of
supported multicast configurations, see the Internetworking Guide of the Windows Server 2003 Resource Kit (or
see the Internetworking Guide on the Web at http://www.microsoft.com/reskit).
Figure 1.14 IP Multicast Components
Planning MADCAP Servers

The Multicast Address Dynamic Client Allocation Protocol (MADCAP), built on a client/server model, enables
a computer to request an IP multicast address from one or more multicast address allocation servers, known as
MADCAP servers. If a client sends a message and does not receive a response, it can retransmit its request.
MADCAP as defined in RFC 2730, “Multicast Address Dynamic Client Allocation Protocol (MADCAP),”
differs substantially and is separate from DHCP. However, the Windows Server 2003 DHCP service combines
support for both the DHCP and MADCAP protocols for IPv4. Although MADCAP is packaged in the DHCP
service, the DHCP and MADCAP services are independent of each other. A DHCP client might or might not be
a MADCAP client, and a MADCAP client might or might not be a DHCP client.
MADCAP Without DHCP

To use the DHCP service to deploy MADCAP servers independently of DHCP servers, create one or more
multicast scopes, but do not create other scopes or superscopes. The MADCAP server also functions as a DHCP
server only if you configure other scopes or superscopes.
MADCAP Security
The IPSec protocol meets MADCAP requirements for client/server identification and integrity protection as
described in RFC 2730, and requires no modifications to the MADCAP protocol. Therefore, when you require
strong security, use IPSec to protect all of the unicast messages of the MADCAP protocol.
For more information about MADCAP, including how to use IPSec in conjunction with MADCAP, see
RFC 2730, “Multicast Address Dynamic Client Allocation Protocol (MADCAP).”
Planning IP Multicast-Enabled Routers

To implement IP multicasting on a multiple-router intranet, you must install routers enabled for multicast
routing and configured with one or more multicast routing protocols.
Windows Server 2003 does not provide any multicast routing protocols. To provide multicast forwarding within
a single-router intranet or when connecting a single-router intranet to the Internet, you can configure the Internet
Group Management Protocol (IGMP) routing protocol component of the Routing and Remote Access service
with interfaces set to IGMP router mode and IGMP proxy mode. The IGMP routing protocol component
exchanges and updates information in the IP multicast forwarding table about host membership in specific
groups.
The IGMP routing protocol is not a multicast routing protocol. To support efficient multicast forwarding and
routing on a multiple-router intranet, you must also install IP multicast-enabled routers that use one or more
multicast routing protocols. Multicast routers use multicast routing protocols to communicate multicast group
information with each other.
Note
You can configure the IGMP router mode and IGMP proxy mode
interfaces to provide multicast forwarding support in multiple-router
intranets, but doing so is not efficient and is therefore not
recommended or supported.
Although Windows Server 2003 does not include any multicast routing protocols, the Routing and Remote
Access service is an extensible platform that can support multicast routing protocols. Multicast routing protocols
include Protocol-Independent Multicast (PIM) in both Sparse Mode (PIM-SM) and Dense Mode (PIM-DM),
Multicast Extensions to OSPF (MOSPF), and the Distance Vector Multicast Routing Protocol (DVMRP). Your
choice of multicast routing protocol will depend on the size and type of network and the distribution of
multicast group members.
• Protocol-Independent Multicast (PIM). The PIM protocol routes to multicast groups whose
members span wide-area and interdomain internetworks. PIM functions independently of any
unicast routing protocol. A multicast group that uses PIM can declare itself sparse or dense,
using either Sparse Mode or Dense Mode:
• Protocol-Independent Multicast Sparse Mode (PIM-SM), the most widely used
multicast routing protocol, is designed for multicast groups whose members are distributed
sparsely across a large region. PIM-SM can operate in a LAN environment but is most
efficient in a WAN environment. Using a dense-mode protocol for a multicast group whose
members are distributed thinly can cause unnecessary transmission and router storage of
data packets or membership report information. This overhead might be acceptable where
multicast group members are populated densely, but it is inefficient for a sparse mode
multicast group. In sparse mode, routers must explicitly join and leave multicast groups,
which eliminates unnecessary traffic and storage.
• Protocol-Independent Multicast Dense Mode (PIM-DM) is a dense-mode multicast
routing protocol designed for multicast groups whose members are distributed thickly over
an area where bandwidth is plentiful. PIM-DM is interoperable with the sparse mode,
PIM-SM. PIM-DM does not scale well.
• Multicast Extensions to OSPF (MOSPF). The MOSPF protocol, an extension of OSPF, is
also a dense-mode multicast routing protocol. MOSPF employs a unicast routing protocol that
requires that each router in a network be aware of all available links. MOSPF is intended for
use on a single organization’s network, and does not scale well. MOSPF requires OSPF as its
accompanying unicast routing protocol. It can sometimes put a heavy load on router CPU
bandwidth.
• Distance Vector Multicast Routing Protocol (DVMRP). The original IPv4 multicast routing
protocol, DVMRP runs over multicast-capable LANs such as Ethernet. DVMRP can also tunnel
IP multicast packets as unicast packets through routers with no multicast capability. DVMRP is
a dense-mode multicast routing protocol that does not scale well.
Configuring IGMP
To support IPv4 multicast applications on a single-router intranet or when connecting a single-router intranet to
the Internet, you can use the Routing and Remote Access service on one or more computers running Windows
Server 2003, add the IGMP routing protocol component on each server, and configure the server’s outbound
interface for IGMP router mode and its inbound interface for IGMP proxy mode. If your multicast applications
cross the Internet, the outbound interface is the intranet interface and the inbound interface is the Internet
interface.
• IGMP router mode on the outbound interface. In Windows Server 2003, an outbound
interface running in IGMP router mode listens for IGMP Membership Report messages and
tracks group membership. Enable IGMP router mode on the interfaces to listening multicast
hosts. The TCP/IP protocol and the IGMP routing protocol component for interfaces running in
IGMP router mode forward multicast traffic.
• IGMP proxy mode on the inbound interface. IGMP proxy mode is designed to pass IGMP
Membership Report messages within a single-router intranet or from a single-router intranet to
the MBone. (As explained earlier, in a multiple-router intranet, you must install routers that use
one or more multicast routing protocols.) With IGMP proxy mode enabled on the inbound
interface, hosts can receive multicast traffic from multicast sources and can send multicast
traffic to other hosts.
Within a single-router intranet, or when connecting a single-router intranet to the Internet, you do not need
routers running multicast routing protocols. However, within a multiple-router intranet that uses multicast
routers running multicast routing protocols, you can still use the Routing and Remote Access service as a
multicast forwarding router on the periphery of your intranet.
RFC 1112, “Host Extensions for IP Multicasting,” defines address and host extensions for IP hosts that support
multicasting, and defines IGMP Version 1. RFC 2236, “Internet Group Management Protocol (IGMP), Version
2,” defines IGMP Version 2. Windows Server 2003 supports IGMP Version 3, described in the Internet Draft
“Internet Group Management Protocol, Version 3.” Under IGMP Version 3, hosts can specify interest in
receiving multicast traffic from specified sources or from all but a specific set of sources.
Configuring IP Multicast Scopes

Multicast addressing supports dynamic membership, under which individual computers can join or leave a
multicast group at any time. Group membership is not limited by size, and computers are not restricted to
membership in any single group.
On all IP networks, each computer must first be configured with its own unicast IP address. After assigning this
unicast address, you can configure the computer to support a multicast address. A multicast group of computers
shares the same multicast IP address. IPv4 multicast addresses range, in dotted decimal notation, from 224.0.0.0
through 239.255.255.255 (224.0.0.0/4). Such a multicast group also uses a MAC-layer multicast address, which
allows all devices to filter unsolicited multicast traffic at the link layer. Ethernet addresses reserved for
multicasting range from 01-00-5E-00-00-00 through 01-00-5E-7F-FF-FF.
Typically, you specify IP address ranges for multicast scopes on your MADCAP server in the following ways:
• Administrative scoping is designed for multicast IP addresses used privately on your intranet.
You use the 239.192.0.0 range of the multicast (Class D) address space with a subnet mask of
255.252.0.0. This is known as the IPv4 Organization Local Scope. It provides 262,144 group
addresses (218) for use in all subnets on your network. For more information about
administrative scoping, see RFC 2365, “Administratively Scoped IP Multicast.”
• Global scoping is designed for multicast IP addresses used on the Internet. You use the
233.0.0.0 range of the multicast address space. Global addresses are allocated in the following
way:
• IANA (or another network registry) allocates and reserves the first 8 bits of the range (the
“233” portion).
• The next 16 bits are based on your Autonomous System (AS) number. For information
about obtaining your existing AS number or acquiring a new one, see “Using Multicast
Scopes” in Help and Support Center for Windows Server 2003.
• The last 8 bits provide the IP address range from which to configure any multicast scopes
for group addresses that you want to use publicly on the Internet. Use a subnet mask of
255.255.255.0.
For more information about global scoping, see RFC 3180, “GLOP Addressing in 233/8.” For
more information about AS numbering, see RFC 1930, “Guidelines for Creation, Selection, and
Registration of an Autonomous System (AS).”
Configuring Client Computers

On participating clients, install and configure the appropriate MADCAP-aware hardware and software. For
example, for video conferencing, install video conferencing software and a video camera, sound card, and audio
headset.
Standards for the multicast transmission of a data stream between the subnets of an internetwork include
RFC 1112, “Host Extensions for IP Multicasting”; RFC 2236, “Internet Group Management Protocol,
Version 2”; and the Internet Draft “Internet Group Management Protocol, Version 3.” Such standards instruct
routers how and where to route multicast traffic.
For more information about IP multicasting, including multiple supported multicast configurations, see the
Internetworking Guide of the Windows Server 2003 Resource Kit (or see the Internetworking Guide on the Web
at http://www.microsoft.com/reskit), and for information about Windows Server 2003 TCP/IP, see the
Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
Introducing IPv6 on Your Network

In addition to the IPv4 stack installed by default, Windows Server 2003 and Windows XP include an IPv6
protocol stack that you can use to test IPv6, to explore IPv6-enabled applications, and to prepare for possible
eventual migration to a native IPv6 infrastructure.
It is expected that IPv4 and IPv6 will coexist on enterprise networks for a number of years. Depending on their
needs, some organizations might continue to use IPv4 exclusively, some will migrate slowly while running both
IPv4 and IPv6 in the interim, and some will maintain IPv4 in one or more sections of their organization and
implement IPv6 in other sections.
To ensure that your organization makes best use of IPv6 capabilities with the least administrative overhead,
include a plan for introducing IPv6 into the design for your TCP/IP network. To prepare to introduce IPv6, you
must explore the new functionality introduced by IPv6, plan IPv6 addressing, plan how to route IPv6 traffic
over an existing IPv4 infrastructure or an IPv6 infrastructure, decide whether to deploy DNS dynamic update,
and decide whether to deploy PortProxy to enable IPv4 applications (where possible) for IPv6. Figure 1.15
shows each task in the planning process.
Figure 1.15 Introducing IPv6 on Your Network

Exploring IPv6
Windows Server 2003 includes an IPv6 stack, in addition to the IPv4 stack, which you can use to explore the
capabilities of IPv6, test new applications and network technologies, and plan the first steps toward the wider
adoption of IPv6 on your network.
The current version of the Internet Protocol — IP version 4, known as IPv4 — dates from 1981 and has not
changed substantially since it was introduced in RFC 791, “Internet Protocol.” Although IPv4 proved to be
remarkably robust and enduring, in the early 1990s the Internet Engineering Task Force (IETF) began to
develop a suite of protocols and standards — IPv6 — to better address the demands of modern networking. Two
of the most important of these protocols are RFC 2460, “Internet Protocol, Version 6 (IPv6) Specification,”
which defines IPv6, and RFC 2463, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification,” which specifies a set of ICMP messages for use with IPv6.
Before considering the design choices that you must make when introducing IPv6 on your network, you must
become familiar with some of the basics about IPv6, including:
• IPv6 features.
• Supported features, server applications, and application programming interfaces (APIs).
• Supported IPv6 tools.
• Types of nodes.
IPv6 Features
The IPv6 protocol includes the following features and improvements over IPv4:
• New header format. The IPv6 header is designed to minimize overhead. Although the IPv6
address field is four times as long as the address field in IPv4, the IPv6 header is only twice as
large as the IPv4 header overall. The more efficient header design enables faster processing at
intermediate routers. Because IPv6 headers are not interoperable with IPv4 headers, and the
IPv6 protocol is not backward compatible with IPv4. A host or router must use an
implementation of both IPv4 and IPv6 in order to recognize and process both header formats.
• Large address space. IPv6 provides 128-bit IP addresses, in contrast with the 32-bit IPv4 IP
addresses. The address space is designed to accommodate a vast number of interconnected
devices on any network, and its structure is designed to reduce the number of routing table
entries in IPv6 routers.
• Hierarchical addressing and routing infrastructure. IPv6 global addresses are designed to
facilitate a hierarchical routing infrastructure that is based on the common occurrence of
multiple levels of ISPs. It is anticipated that the routing tables for backbone routers on the IPv6
Internet will be much smaller and, as a result, will be processed much more efficiently.
• Automatic address configuration. IPv6 simplifies address configuration and renumbering by

enabling automatic address configuration for all hosts. Host interfaces automatically learn their
addresses through interactions with local IPv6 routers. They can learn new addresses on the fly,
making network renumbering much simpler than in IPv4.
• Integrated network security. Support for IPSec is an IPv6 protocol suite requirement.
• Better support for Qualify of Service (QoS). The IPv6 header contains a new field that can be
used to determine how to identify and prioritize traffic. Because the traffic type can be
identified within the IPv6 header, support for QoS is available even when IPSec encryption is in
use.
• New protocol for neighboring node interaction. The IPv6 Neighbor Discovery protocol is a
series of Internet Control Message Protocols for IPv6 messages (ICMPv6) that manage the
interaction of nodes on the same link. Neighbor Discovery replaces broadcast-based Address
Resolution Protocol (ARP), ICMPv4 Router Discovery, and ICMPv4 Redirect messages with
efficient multicast and unicast Neighbor Discovery messages.
• Extensibility. IPv6 can be easily extended to incorporate new features by adding extension
headers after the IPv6 header. The size of IPv6 extension headers is limited only by the size of
the IPv6 packets.
Supported Features, Server Applications, and APIs

Windows Server 2003 supports IPv6 functionality for a wide range of services. Table 1.3 shows which IPv6
features Windows Server 2003 IPv6 supports.
Table 1.3 IPv6 Features Supported by Windows Server 2003 IPv6
Supported by Windows
IPv6 Feature
Server 2003 IPv6
Installation Yes
(Use Add protocol GUI, or use the Netsh
command-line tool)
Uninstallation Yes
(Use Remove protocol GUI, or use the Netsh
command-line tool)
Dual IPv6/IPv4 stack Yes
6to4 Yes
ISATAP Yes
6over4 (manual) Yes
IPv6 NAT Traversal No
(also referred to as Teredo)
(continued)
Table 1.3 IPv6 Features Supported by Windows Server 2003 IPv6 (continued)
IPv6 Feature
Server 2003 IPv6
DNS over IPv6 Yes
(also referred to as DNS AAAA records)
Linklocal Multicast Name Resolution (LLMNR) No
DNS dynamic update Yes
DHCP No
TCP PortProxy Yes
Remote Desktop No
Remote Assistance No
IPv6 Management Information Base (MIB) for Yes
Simple Network Management Protocol (SNMP)
Microsoft Network Monitor version 2 (Netmon) Yes
Visual Studio .NET (VS.NET) Yes
IPSec authentication Yes
IPSec encryption No
Table 1.4 shows which server applications Windows Server 2003 IPv6 supports.
Table 1.4 Server Applications Supported by Windows Server 2003 IPv6
Server Applications
Server 2003 IPv6
File sharing, printer sharing Yes
Windows Media Server Yes
Internet Information Services (IIS) 6.0 (HTTP only) Yes
Telnet server Yes
FTP server No
Active Directory No
Microsoft® Exchange Server No
SQL Server™ No
Windows Server 2003 IPv6 also supports Internet Explorer. However, it does not include support for literal
addresses.
In addition, the following APIs support Windows Server 2003 IPv6:
• .NET Framework
• Windows Sockets 2 (Winsock2) API
• Remote procedure call (RPC)
• Distributed Component Object Model (DCOM)
• Windows Internet (WinINet) API (does not include support for literal addresses)
• Windows HTTP Services (WinHTTP)
• HTTP.sys
• IP Helper API (IPHLPAPI) module
• Debuggers
Supported IPv6 Tools

Windows Server 2003 IPv6 supports the following tools.
• Ping
• Tracert
• Pathping
• Ipconfig
• Route
• Netsh (Use netsh interface IPv6 commands)
• Netstat
• Nslookup
• Telnet client
• FTP client
For more information about these TCP/IP tools and commands, see the Networking Guide of the Windows
Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
Types of Nodes
To understand IPv6 tunneling technologies, such as 6to4 and ISATAP (described later), you must understand the
types of nodes that might be involved. Table 1.5 shows IPv4 and IPv6 node types.
Table 1.5 IPv4 and IPv6 Node Types
Node Type Description
IPv4-only node A device that can communicate only with IPv4
nodes and applications and that does not
support IPv6.
IPv6-only node A device that can communicate only with IPv6
nodes and that does not support IPv4.
IPv6/IPv4 node A device that implements both IPv4 and IPv6 and
that can communicate with either IPv6 or IPv4
nodes and applications.
IPv4 node Any device that supports IPv4. Both IPv4-only
and IPv6/IPv4 nodes are IPv4 nodes.
IPv6 node Any device that supports IPv6. Both IPv6-only
and IPv6/IPv4 nodes are IPv6 nodes.
For more information about the different node types, see RFC 2893, “Transition Mechanisms for IPv6 Hosts
and Routers.”
Planning IPv6 Addressing

To plan an efficient IPv6 addressing strategy, you must understand how IPv6 addressing works. IPv6 addressing
is a major departure from IPv4 addressing. The most obvious difference is that IPv4 uses 4-byte source and
destination addresses, typically expressed in the familiar dotted-decimal notation, whereas IPv6 uses 16-byte
addresses, typically expressed in colon-hexadecimal notation. Colon-hexadecimal notation uses eight 4-digit
hexadecimal numbers, with colons separating the 16-bit blocks (the 4-digit numbers).
To manage addresses more easily, IPv6 suppresses leading zeros and compresses a single contiguous all-zero
16-bit block, representing the contiguous block with two colons (::) (known as double-colon compression).
Table 1.6 shows the effects of suppressing leading zeros and double-colon compression on the notation for an
IPv6 address.
Table 1.6 Leading Zero Suppression and All-Zero Contiguous Block Compression
IPv6 Address Notation IPv6 Address
IPv6 address FEC0:0000:0000:0000:02AA:00FF:FE3F
:2A1C
IPv6 address with leading zeros FEC0:0:0:0:2AA:FF:FE3F:2A1C
suppressed
IPv6 address with leading zeros FEC0::2AA:FF:FE3F:2A1C
suppressed and an all-zero contiguous
block compressed
The 16 bytes, or 128 bits, provided in the IPv6 address space potentially supports 2128 addresses. However, the
purpose of this large address space is not only to provide an inexhaustible supply of addresses, but also to enable
a hierarchical routing infrastructure that can be summarized. IPv6 addressing is designed to minimize the size of
routing tables and to reduce routing complexity.
IPv6 supports address configuration both in the presence of a DHCP server, known as stateful address
configuration, and in the absence of a DHCP server, known as stateless address configuration. Stateless address
configuration introduces the use of link-local addresses, whereby hosts on the same link automatically configure
themselves with IPv6 addresses for that link and can use those addresses to communicate with the other hosts on
the same link. If one or more local routers exist, hosts can use router discovery to automatically determine the
routers’ addresses and can then communicate with IPv6 hosts beyond the local link.
As in IPv4, the high-order bits in an IPv6 address identify the type of address. In IPv6, the high-order bits are
known as the Format Prefix (FP). IPv6 does not use subnet masks to specify the network ID. Instead, it uses
only prefix notation.
IPv6 Address Types

IPv6 has three types of addresses, which can be categorized by type and scope:
• Unicast addresses. A packet is delivered to one interface.
• Multicast addresses. A packet is delivered to multiple interfaces.
• Anycast addresses. A packet is delivered to the nearest of multiple interfaces (in terms of
routing distance).
IPv6 does not use broadcast messages.
Unicast and anycast addresses in IPv6 have the following scopes (for multicast addresses, the scope is built into
the address structure):
• Link-local. The scope is the local link (nodes on the same subnet).
• Site-local. The scope is the organization (private site addressing).
• Global. The scope is global (IPv6 Internet addresses).
In addition, IPv6 has special addresses such as the loopback address. The scope of a special address depends on
the type of special address.
Much of the IPv6 address space is unassigned.
Unicast IPv6 Addresses

IPv6 has several major unicast address types.
Unicast global addresses
IPv6 unicast global addresses are similar to IPv4 public addresses. Also known as aggregatable global unicast
addresses, global addresses are globally routable. The structure of an IPv6 unicast global address creates the
three-level topology shown in the following illustration.
Table 1.7 explains each field in a unicast global address.

Table 1.7 Fields in a Unicast Global Address
Field Description
001 Identifies the address as an IPv6 unicast global
address.
Top Level Aggregation Identifier Identifies the highest level in the routing
(TLA ID) hierarchy. TLA IDs are administered by IANA,
which allocates them to local Internet registries,
which then allocate a given TLA ID to a global
ISP.
Res Reserved for future use (to expand either the
TLA ID or the NLA ID).
Next Level Aggregation Identifier Identifies a specific customer site.
(NLA ID)
Site Level Aggregation Identifier Enables as many as 65,536 (216) subnets within
(SLA ID) an individual organization’s site. The SLA ID is
assigned within the site; an ISP cannot change
this part of the address.
Interface ID Identifies the interface of a node on a specific
subnet.
Unicast site-local addresses

IPv6 unicast site-local addresses are similar to IPv4 private addresses. The scope of a site-local address is the
internetwork of an organization’s site. (You can use both global addresses and site-local addresses in your
network.) The prefix for site-local addresses is FEC0::/48.
The following illustration shows the structure of a site-local address.
The initial 48 fixed bits are followed by a 16-bit Subnet ID field, which provides as many as 65,536 subnets in
a flat subnet structure. Alternatively, you can subdivide the high-order bits of the Subnet ID field to create a
hierarchical routing infrastructure. The last field is a 64-bit Interface ID field that identifies the interface of a
node on a specific subnet.
Note
Global addresses and site-local addresses share the same structure
after the first 48 bits — the 16-bit SLA ID of a global address and the
16-bit Subnet ID of a site-local address both identify the subnets of an
organization’s site. Because of this, you can assign a specific subnet
number to identify a subnet that is used for both global and site-local
unicast addresses.
Unicast link-local addresses (FE80::/64)

IPv6 unicast link-local addresses are similar to IPv4 APIPA addresses used by computers running Microsoft
Windows. Hosts on the same link (the same subnet) use these automatically configured addresses to
communicate with each other. Neighbor Discovery provides address resolution. The prefix for link-local
addresses is FE80::/64. The following illustration shows the structure of a link-local address.
Unicast unspecified address

The IPv6 unicast unspecified address is equivalent to the IPv4 unspecified address of 0.0.0.0. The IPv6
unspecified address is 0:0:0:0:0:0:0:0:, or a double colon (::).
Unicast loopback address
The IPv6 unicast loopback address is equivalent to the IPv4 loopback address, 127.0.0.1. The IPv6 loopback
address is 0:0:0:0:0:0:0:1, or ::1.
Unicast 6to4 addresses (2002::/16)

IPv6 uses 6to4 addresses to communicate between two IPv6/IPv4 nodes over the IPv4 Internet. A 6to4 address
combines the prefix 2002::/16 with the 32 bits of the public IPv4 address of the node to create a 48-bit prefix —
2002:WWXX:YYZZ::/48, where WWXX:YYZZ is the colon-hexadecimal representation of w.x.y.z, a public IPv4
address. Therefore, the IPv4 address 157.60.91.123 translates into a 6to4 address prefix of
2002:9D3C:5B7B::/48.
The following illustration shows the structure of a 6to4 address.
However, this is often written using the hexadecimal prefix: 2002:WWXX:YYZZ:SLA ID:Interface ID.
The following example shows how the WWXX:YYZZ portion of the address is translated from colon-
hexadecimal notation to dotted-decimal notation. In this example, 9D3C:5B7B translates to 157.60.91.123, as
illustrated in the following example.
Use a calculator to convert each constituent
Notation Type number
from one notation type to the other
Colon-hexadecimal 9D 3C 5B 7B
Dotted-decimal 157 60 91 123
For more information about 6to4 tunneling, see “Routing IPv6 Traffic over an IPv4 Infrastructure” later in this
chapter.
Unicast ISATAP addresses
IPv6 uses ISATAP addresses to communicate between two IPv6/IPv4 nodes over an IPv4 intranet. An ISATAP
address combines a 64-bit unicast link-local, site-local, or global prefix (a global prefix might be a 6to4 prefix)
with a 64-bit suffix constructed of the ISATAP identifier 0:5EFE, followed by the IPv4 address assigned to an
interface of the host. The prefix is known as the subnet prefix. Although a 6to4 address can incorporate only a
public IPv4 address, an ISATAP address can incorporate either a public or a private IPv4 address.
The following illustration shows the structure of an ISATAP address.
Table 1.8 shows an example of each type of ISATAP address.

Table 1.8 Examples of ISATAP addresses
Type of ISATAP Address ISATAP Address
With link-local prefix FE80::5EFE:131.107.129.8*
With site-local prefix FEC0::1111:0:5EFE:131.107.129.8*
With global prefix 3FFE:1A05:510:1111:0:5EFE:131.107.129.8*
With global 6to4 prefix 2002:9D36:1:2:0:5EFE:131.107.129.8*
*Alternatively, the IPv4 address (in this example, 131.107.129.8) can be written in hexadecimal (in
this example, 836B:8108).
By default, the IPv6 protocol for Windows XP and members of Windows Server 2003 automatically configures
the ISATAP address of FE80::5EFE:w.x.y.z for each IPv4 address that is assigned to the node. This link-local
ISATAP address allows two hosts to communicate over an IPv4 network by using each other’s ISATAP address.
For more information about ISATAP tunneling, see “Routing IPv6 Traffic over an IPv4 Infrastructure” later in
this chapter.
Multicast IPv6 Addresses

IPv6 multicast addresses are similar to IPv4 multicast addresses. Packets addressed to a multicast address are
delivered to all interfaces that the address identifies.
The following illustration shows the structure of an IPv6 multicast address.
Table 1.9 explains each field in an IP multicast address. The prefix for multicast addresses is FF00::/8.
Table 1.9 Fields in a Multicast Address
Field Description
1111 1111 Identifies the address as an IP multicast address.
Flags Currently, the only defined flag is the Transient (T) flag.
Set to zero, the T flag identifies the address as a
permanently assigned multicast address. Set to 1, it
identifies a transient address.
Scope Indicates the scope of the multicast traffic, such as
interface-local, link-local, site-local, organization-local, or
global scope.
Group ID identifies the multicast group.
Multicast solicited node address

The IPv6 multicast solicited node address is used for efficient address resolution. The IPv4 ARP Request frame
is sent to the MAC-level broadcast, which disturbs all nodes on the network segment. The multicast solicited
node address combines the prefix FF02::1:FF00:0/104 with the last 24 bits of the IPv6 address being resolved.
IPv6 uses the solicited node multicast address for the Neighbor Solicitation message (the IPv6 equivalent to the
ARP Request frame) that resolves an IPv6 address to its link-layer address, disturbing few nodes during the
address resolution process.
Anycast IPv6 Addresses

Anycast IPv6 addresses are similar to but more efficient than the anycast addresses in IPv4, which are used
primarily by large ISPs. Anycast addresses use the unicast address space but function differently from other
unicast addresses. IPv6 uses anycast addresses to identify multiple interfaces. IPv6 delivers packets addressed to
an anycast address to the nearest interface that the address identifies. In contrast to a multicast address, where
delivery is from one to many, an anycast address delivery is from one to one-of-many. Currently, anycast
addresses are assigned only to routers and are used only as destination addresses.
IPv6 Addresses Assigned to Hosts and Routers

An IPv6 host, including those with only one interface, typically has multiple IPv6 addresses. By default, link-
local addresses are automatically configured for each interface on each IPv6 host or router. To communicate
with non-neighboring nodes, a host must also be configured with unicast site-local or global addresses. A host
obtains these additional addresses either from router advertisements or by manual assignment. Use commands in
the netsh interface ipv6 context to manually configure IPv6 addresses.
In IPv6, hosts and routers are typically assigned the following addresses:
• Unicast addresses:
• A link-local address for each interface
• A site-local address for each interface
• One or more global addresses for each interface
• The loopback address for the loopback interface
• Multicast addresses (to listen for multicast traffic):

• The interface-local scope all-nodes address (FF01::1)
• The link-local scope all-nodes address (FF02::1)
• The solicited node address for each unicast address on each interface
• The multicast address for each joined group on each interface
In addition, IPv6 routers also have the following addresses:
• Multicast addresses:
• The interface-local scope all-routers address (FF01::2)
• The link-local scope all-routers address (FF02::2)
• The site-local scope all-routers address (FF05::2)
• Anycast addresses:
• A subnet-router anycast address for each subnet
• Optional — Additional anycast addresses
Table 1.10 summarizes the major differences between IPv6 and IPv4 addresses.
Table 1.10 Differences Between IPv4 Addressing and IPv6 Addressing
IPv4 Address IPv6 Address
Internet address classes N/A
Multicast addresses (224.0.0.0/4) IPv6 multicast addresses (FF00::/8)
Broadcast addresses N/A
Unspecified address is 0.0.0.0 Unspecified address is ::
Loopback address is 127.0.0.1 Loopback address is ::1
Public IP addresses Aggregatable global unicast addresses
Private IP addresses Site-local addresses (FEC0::/48)
Autoconfigured addresses Link-local addresses (FE80::/64)
Dotted decimal notation Colon hexadecimal format
Subnet mask or prefix length notation Prefix length notation only
A resource records AAAA resource records
Routing IPv6 Traffic over an IPv4

Infrastructure
An eventual successful transition to IPv6 requires interim coexistence of IPv6 nodes in today’s predominantly
IPv4 environment. To support this, IPv6 packets are automatically tunneled over IPv4 routing infrastructures,
enabling IPv6 clients to communicate with each other by using 6to4 or ISATAP addresses and tunneling IPv6
packets across IPv4 networks. For information about automatic tunneling of IPv6 packets, see RFC 2893,
“Transition Mechanisms for IPv6 Hosts and Routers.”
Support for IPv6 automatic tunneling technologies in Windows XP and Windows Server 2003 includes:
• 6to4, to provide automatic intersite tunnels across the IPv4 Internet.
• ISATAP, to provide automatic intrasite tunnels.
A computer running Windows XP or Windows Server 2003 can automatically configure itself for 6to4 and
ISATAP tunneling. The IPv6 Helper service, included with the IPv6 protocol for Windows XP and Windows
Server 2003, provides support for 6to4 hosts and 6to4 routers. Use netsh interface IPv6 isatap context
commands to configure the IPv6 Helper service. In addition, you can configure a computer running
Windows XP or Windows Server 2003 as a 6to4 router by enabling the Internet Connection Sharing (ICS)
feature on the interface that is connected to the Internet.
Both 6to4 and ISATAP encapsulate an IPv6 packet within an IPv4 header. However, they send the packet across
an IPv4 infrastructure in different ways:
• 6to4 uses the IPv6 prefix. 6to4 uses a public IPv4 address to create the 64-bit subnet identifier
portion for an IPv6 address. For example, 131.107.71.152 becomes 2002:836B:4798::/48.
• ISATAP uses the IPv6 interface ID. ISATAP uses a locally assigned IPv4 address (public or
private) to create a 64-bit interface identifier. For example, 172.31.71.152 becomes
::0:5EFE:172.31.71.152.
In both cases, IPv4 addresses that are embedded in portions of the IPv6 address provide the information to
determine the source and destination addresses in the encapsulating IPv4 header.
By deploying 6to4 or ISATAP, you can integrate IPv6 traffic into your IPv4 network environment.
Understanding examples of each automatic tunneling technology can help you decide whether to deploy 6to4,
ISATAP, or both as you introduce IPv6 on your network.
Note
For an introduction to IPv6, including information about router-to-router,
host-to-router, router-to-host, and host-to-host tunneling configurations
that underlie 6to4 and ISATAP tunneling, see the Networking Guide of
the Windows Server 2003 Resource Kit (or see the Networking Guide
on the Web at http://www.microsoft.com/reskit).
Using 6to4 for IPv6 Traffic Between Subnets or Between Sites

6to4 is an address assignment and router-to-router automatic tunneling technology that is described in
RFC 3056, “Connection of IPv6 Domains via IPv4 Clouds.” To facilitate the introduction of IPv6 in current
IPv4 environments, IPv6 is designed so that you can use 6to4 to handle traffic between IPv6 nodes without
obtaining an IPv6 global address prefix from an IPv6 ISP, and without a direct connection to the IPv6 Internet.
Figure 1.16 shows one way to use 6to4 to handle the following types of traffic:
• Direct 6to4 host communication within a site (no tunnel). A 6to4 host can communicate
directly with another 6to4 host within the same site. A 6to4 host is an IPv6 host that is
configured with at least one 6to4 address (a global address with the 2002::/16 prefix). Host A
and Host B in Figure 1.16 use the local 6to4 router to communicate with each other.
• Tunnel across the IPv4 Internet by using a 6to4 router. A 6to4 host can communicate with a
non-local 6to4 host by using a tunnel from a local 6to4 router across an IPv4 network (such as
the Internet) to a 6to4 router at the destination site. The first 6to4 router encapsulates the packet
in an IPv4 header; the receiving 6to4 router removes the IPv4 header and then forwards the
IPv6 packet to the destination 6to4 host. During the first and last stages of the packet’s
transmission — from the sending 6to4 host to its 6to4 router, and from the recipient 6to4 router
to the destination 6to4 host — the IPv6 routing infrastructure in place at each site is used. In
Figure 1.16, 6to4 Host A (or 6to4 Host B) sends its packet to 6to4 Router 1, which tunnels it
across the IPv4 Internet to 6to4 Router 2, which then forwards the packet to 6to4 Host C.
• Tunnel across the IPv4 Internet to the IPv6 Internet by using a 6to4 router and a 6to4
relay. A 6to4 host on an IPv4 network can communicate with an IPv6-only host on the IPv6
Internet by using a tunnel from a local 6to4 router across the IPv4 Internet to a 6to4 relay that
then forwards the packet across the IPv6 Internet to the recipient IPv6-only host. In this case, it
is the 6to4 relay that removes the IPv4 header and forwards the IPv6 packet to the recipient
IPv6-only host. In Figure 1.16, Host A (or Host B) sends its packet to 6to4 Router 1, which
tunnels it across the IPv4 Internet to the 6to4 relay, which then forwards the packet to 6to4
Host D.
Figure 1.16 Using 6to4 to Route IPv6 Packets
In Figure 1.16, 6to4 Router 2 represents a computer running Windows XP with ICS enabled. The private
interface of the ICS computer connects to a single-subnet intranet, and the ICS computer’s public interface
connects to the IPv4 Internet. The private interface of an ICS computer always uses the private IPv4 address
192.168.0.1.
Using ISATAP for IPv6 Traffic Between Subnets

Intrasite Automatic Tunnel Addressing Protocol (ISATAP) is an address assignment and automatic tunneling
technology that is described in the Internet Draft “Intrasite Automatic Tunnel Addressing Protocol (ISATAP).”
ISATAP enables unicast communication between IPv6/IPv4 nodes in an IPv4 intranet.
ISATAP derives an interface identifier (the last 64 bits of an IPv6 address) from any IPv4 address assigned to
the node, either public or private. The ISATAP address format supports configuration of global addresses
(including 6to4), site-local addresses, and link-local addresses.
Figure 1.17 shows two IPv6/IPv4 hosts communicating over an IPv4 network by using each other’s
automatically configured link-local ISATAP address.
Figure 1.17 Using Link-Local ISATAP Addresses to Route IPv6 Packets on an IPv4 Network
IPv6/IPv4 hosts can also communicate with non-local IPv6/IPv4 hosts by using ISATAP-derived global
addresses, and by using an ISATAP router to tunnel packets through an IPv4 infrastructure. Under the IPv6
protocol that Windows XP and Windows Server 2003 support, you can use either of the following methods to
configure the intranet IPv4 address of an ISATAP router:
• Name resolution (preferred). For computers running Windows XP (SP1 or later) or Windows
Server 2003, automatic resolution of the name ISATAP to an IPv4 address. To ensure successful
name resolution, name the computer used as the ISATAP router ISATAP. A computer running
Windows XP or Windows Server 2003 then automatically registers the appropriate records in
DNS and WINS. For computers running Windows XP (earlier than SP1), the name resolved is
_ISATAP.
• Netsh commands for Interface IPv6. Manual configuration by using commands in the Netsh
Interface IPv6 context.
An ISATAP host sends an IPv4-encapsulated Router Solicitation message to a configured ISATAP router. The
ISATAP router responds with an IPv4-encapsulated unicast Router Advertisement message that contains
prefixes for use in autoconfiguring ISATAP-based addresses. This additional configuration is needed only when
the host’s subnet does not contain an IPv6 router.
The example in Figure 1.18 shows how two ISATAP hosts that use 6to4 prefixes can communicate across the
Internet even though each site is using the 192.168.0.0/16 private address space.
Figure 1.18 Using 6to4 and ISATAP to Route IPv6 Packets Across the IPv4 Internet
Note
Hosts running Windows XP or Windows Server 2003 determine
whether to use 6to4, ISATAP, or both depending on their IPv4
configuration.
Configuring DNS for IPv6/IPv4 Coexistence

Through DNS dynamic update, DNS client computers register and dynamically update their resource records
with a DNS server whenever an IP address changes. This reduces the need to manually administer zone files,
especially for clients that frequently move or change locations and that use DHCP to obtain an IP address.
In an IPv4 environment, by default the DNS Client service on computers running Windows 2000, Windows XP,
or Windows Server 2003 dynamically updates host (A) resource records (RRs) in DNS. If all hosts on your
network run those operating systems, DNS dynamic updates are automatic.
However, on hosts that do not support dynamic update, you must either enable dynamic update or manually add
or update their DNS records. The same is true on a network to which IPv6 has been introduced: hosts that do not
support dynamic update must have dynamic update enabled or must have DNS records added manually. IPv6
has the additional requirement that IPv6 nodes use a new type of address resource record, known as AAAA
(quad-A) resource records, to resolve a fully qualified domain name to an IPv6 address. (Four “A”s are used for
the name of these resource records because 128-bit IPv6 addresses are four times as large as 32-bit IPv4
addresses.)
Systems that support IPv6 use the same domain names as the domain names used in IPv4 but have both IPv6
and IPv4 addresses registered in DNS. The DNS Server service in Windows Server 2003 and Windows 2000
support processing for DNS IPv6 host records as defined in RFC 1886, “DNS Extensions to Support IP
Version 6.”
An IPv6 host sends DNS name queries to the DNS server to resolve host names to IPv6 addresses. The AAAA
resource records stored on the DNS server provide the mapping from a host name to its IPv6 address.
DNS traffic is also supported over IPv6 for both client and server. The client and server are configured for IPv6
over DNS using anycast or unicast DNS server IP addresses. For more information, see “IPv6 configuration
items” in Help and Support Center for Windows Server 2003.
Because IPv6 addresses are too long to remember easily, you can populate your DNS servers with IPv6 address
resource records to support IPv6 name-to-address resolutions and optionally with pointer resource records to
support IPv6 address-to-name resolutions:
• Address Resource Records. To successfully resolve names to addresses, the DNS
infrastructure must contain the following resource records, populated either manually or
dynamically:
• A resource records for the IPv4 addresses of IPv4 nodes.
• AAAA resource records for the IPv6 addresses of IPv6 nodes. The following is an example
of a AAAA resource record:
host1.microsoft.com IN AAAA FEC0::2AA:FF:FE3F:2A1C
• Pointer (PTR) Resource Records (optional; not recommended). The DNS infrastructure can
also contain the following resource records, populated either manually or dynamically, to
resolve addresses to host names in reverse queries:
• PTR records in the IN-ADDR.ARPA domain for the IPv4 addresses of IPv4 nodes.
• PTR records in the IP6.ARPA domain for the IPv6 addresses of IPv6 nodes. (Recall that
RFC 3152 specifies that IP6.INT be phased out and replaced by IP6.ARPA.) The IP6.INT
domain was created specifically for IPv6 reverse queries. To create the namespace for
reverse queries, each hexadecimal digit in the 32-digit IPv6 address (zero compression and
double-colon compression notation cannot be used) becomes a separate level in inverse
order in the reverse domain hierarchy. Therefore, the reverse lookup domain name for the
address FEC0::2AA:FF:FE3F:2A1C is:
C.1.A.2.F.3.E.F.F.F.0.0.A.A.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.C.E.F.IP6.INT
Avoid integrating PTR resource record support into your DNS infrastructure; the results can be
unreliable.
For name-to-address resolution, after the querying node obtains the set of addresses corresponding to the name,
that node must determine the best set of addresses to use as the source and destination for outbound packets.
While name-to-address resolution is fairly straightforward in an IPv4-only environment, it becomes more
complex in an environment in which IPv4 and IPv6 coexist. In the mixed IPv6/IPv4 scenario, a DNS query can
return both IPv4 and IPv6 addresses. The querying host is configured with at least one IPv4 address and,
typically, multiple IPv6 addresses. Determining the type of address (IPv4 versus IPv6), and then the scope of the
address (for IPv4, public versus private; for IPv6, link-local versus site-local versus global versus coexistence),
for both the source and the destination addresses is complex.
Two algorithms, one to select the source address and another to select the destination address, specify default
behavior for IPv6 implementations. These algorithms do not override choices made by applications or upper-
layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The
two algorithms include an optional mechanism that lets you override the default behavior. In dual-stack
implementations, the destination address selection algorithm considers both IPv4 and IPv6 addresses, and
determines whether it prefers IPv6 addresses over IPv4 addresses, or vice-versa.
For more information about default address selection rules for IPv6, including the source address selection
algorithm and the destination address selection algorithm, see the Internet Draft “Default Address Selection for
IPv6.”
For an introduction to IPv6 and more information about Windows Server 2003 IPv6, see the Networking Guide
of the Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at
http://www.microsoft.com/reskit), or see the IPv6 link on the Web Resources page at
http://www.microsoft.com/windows/reskits/webresources.
Enabling IPv4 Applications for IPv6

You can use the PortProxy service as an application-layer gateway for nodes or applications that do not support
IPv6. PortProxy facilitates the communication between nodes or applications that cannot connect using a
common address type, Internet layer protocol (IPv4 or IPv6), and TCP port. The primary purpose of the service
is to allow IPv6 nodes to communicate with IPv4 TCP applications.
PortProxy relays TCP traffic from IPv4 to either IPv4 or IPv6, or from IPv6 to either IPv6 or IPv4. In the
context of IPv6/IPv4 coexistence or migration, use the PortProxy service to enable any of the following
scenarios:
• An IPv6 node accessing an IPv4-only application that is running on an IPv4 node.
• An IPv4-only node accessing an IPv6-only node.
• An IPv6-only node accessing an IPv4-only node.
The Netsh commands for Interface Portproxy provide a command-line tool for administering servers that act as
proxies between IPv4 and IPv6 networks and applications. For more information about how to use the Netsh
Interface PortProxy commands, see the Netsh command-line help, or see “Netsh commands for Interface Port
Proxy” in Help and Support Center for Windows Server 2003.
Note
The PortProxy service transmits only TCP traffic for application-layer
protocols that do not embed address or port information in the TCP
segment. For example, the File Transfer Protocol (FTP), which embeds
addresses when using the FTP Port command, does not work across a
PortProxy computer. Unlike NAT, the PortProxy service does not
include an equivalent to NAT editors.
Testing Your Design

After acquiring any new hardware and software that your network design requires, systematically measure the
new solution against your organization’s business and technical goals. Testing your design before deploying it in
a production environment ensures that those goals are met with minimum impact.
Predeployment testing lets you assess the performance characteristics of network devices and technologies.
Testing also helps you identify deployment-related risks, and instills confidence in the deployment process
throughout your organization.
Figure 1.19 shows the process for testing a TCP/IP network design.
Figure 1.19 Testing Your Network Design
Reviewing Industry Tests

Vendors, trade journals, and independent test labs extensively test devices and other network solutions. You
might find their published results useful for validating or rejecting assumptions. Keep in mind that most lab tests
are component tests rather than system tests and can fail to measure how a particular network design might
impact the performance of the specific device or technology.
Using Network Testing Tools

Use the following types of tools to test your network design:
• Modeling and simulation tools
• Network management and monitoring tools
Modeling and simulation tools
Use statistical analysis and modeling techniques to simulate a mathematical model of a network. By creating a
model, you can isolate potential performance problems before you actually deploy any part of an IP network. In
most cases, these tools do not measure actual traffic behavior, so evaluate the results with this limitation in
mind.
Network management and monitoring tools
Typically, you use network management and monitoring tools after deploying a network. However, these tools
can also help you test your IP network design in a lab. You can use a number of effective commercially
available network management applications to identify problems and potential problems on your test network.
Many of these applications run on dedicated network management stations (NMSs) and communicate with
internetworking devices using Simple Network Management Protocol (SNMP) or Remote Monitoring (RMON).
By using data supplied by an SNMP or RMON Management Information Base (MIB) located on the devices, a
network management application can isolate performance problems in a proposed network design.
Windows Server 2003 includes the Network Monitor tool (Netmon.exe), a protocol analyzer that you can use to
monitor a new network design. Network Monitor captures and displays packets, analyzing their traffic patterns,
rate of broadcast, errors, utilization, and other aspects of their behavior.
The Network Monitor component that ships with Windows Server 2003 can capture frames that are sent to or
from the computer on which Network Monitor is installed. To capture frames that are sent to or from a remote
computer, you can use the Network Monitor component that ships with Microsoft® Systems Management
Server (SMS), which can capture frames sent to or from any computer on which the Network Monitor driver is
installed.
For more information about the Network Monitor component, see Help and Support Center for Windows
Server 2003. For more information about the SMS Network Monitor component, see the SMS Downloads link
on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
Additional Resources
These resources contain additional information related to this chapter.
Related Information
• “Deploying IPSec” in this book for more information about using Internet Protocol security
(IPSec).
• “Deploying ISA Server” in this book for more information about deploying Network Address
Translation (NAT).
• The Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide
on the Web at http://www.microsoft.com/reskit) for more information about TCP/IP, IPSec, and
IPv6 in Windows Server 2003.
• The Internetworking Guide of the Windows Server 2003 Resource Kit (or see the
Internetworking Guide on the Web at http://www.microsoft.com/reskit) for technical
information about unicast IP routing, including the NAT routing protocol component of the
Routing and Remote Access service.
• “Planning for Deployment” in Planning, Testing, and Piloting Deployment Projects of this kit
for more information about inventorying your network hardware and software and creating a
map of your network topology.
• Cisco Internetwork Design by Matthew Birkner, 2000, Indianapolis, IN: Cisco Press for more
information about the three-tier network design model.
• Top-Down Network Design by Priscilla Oppenheimer, 1999, Indianapolis, IN: Cisco
Press/Macmillan Technical Publishing for more information about the three-tier network design
model.
• Understanding IPv6 by Joseph Davies, 2002, Redmond, WA: Microsoft Press.
• Microsoft Windows Server 2003 TCP/IP Protocols and Services Technical Reference by Joseph
Davies and Thomas Lee, 2002, Redmond, WA: Microsoft Press.
• Routing in the Internet (2nd Edition) by Christian Huitema, 2000, Upper Saddle River, NJ:
Prentice Hall PTR.
• Interconnections (2nd Edition) by Radia Perlman, 2000, Reading, MA: Addison-Wesley.
Related Tools
• Netsh commands for Interface IPv6
You can use the Netsh commands for Interface IPv6 to manage configuration of the IPv6
protocol. For more information about how to use the Netsh commands for Interface IPv6, see
the Netsh command-line help or see “Netsh commands for Interface IPv6” in the Help and
Support Center for Windows Server 2003.
• Netsh commands for Interface Portproxy
The Netsh commands for Interface Portproxy provide a command-line tool for administering
servers that act as proxies between IPv4 and IPv6 networks and applications. For more
information about how to use the Netsh Interface PortProxy commands, see the Netsh
command-line help or see “Netsh commands for Interface PortProxy” in Help and Support
Center for Windows Server 2003.
• Ipsec6.exe
For experimenting with IPSec for IPv6, you can use the Ipsec6 tool to configure IPSec policies
and security associations in an IPv6 environment. For more information about Ipsec6, see “IPv6
Utilities” in Help and Support Center for Windows Server 2003.
• Network Monitor (Netmon.exe)
The Network Monitor tool (Netmon.exe) is a protocol analyzer that you can use to monitor a
new network design. For more information about Netmon.exe, see “Network Monitor” in Help
and Support Center for Windows Server 2003.
Related Help Topics
• For best results in identifying Help topics by title, in Help and Support Center, under the
Search box, click Set search options. Under Help Topics, select the Search in title only
checkbox.
• “Using Multicast Scopes” in Help and Support Center for Windows Server 2003.
• “Netsh commands for Interface PortProxy” in Help and Support Center for Windows
Server 2003.

04 CHAPTER 1 Designing A TCP and IP Network

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

04 CHAPTER 1 Designing A TCP and IP Network

Uploaded by

Copyright:

Available Formats

C H A P T E R 1

Overview of Designing a TCP/IP

Process for Designing a TCP/IP Network

Windows Server 2003 TCP/IP Background

Benefits of Windows Server 2003 TCP/IP

Planning the IP-Based

Designing the Access Tier

Designing the Distribution Tier

Designing the Core Tier

Developing Routing Strategies

Choosing Hardware or Software Routing

Choosing Static or Dynamic Routing

Dynamic Routing Protocols

Distance Vector Routing Protocols

Link State Routing Protocols

Selecting the Appropriate Routing Protocol

Figure 1.5 Designing an IP Addressing Scheme

Creating a Structured Address Assignment

Planning Classless IP Addressing

Determining the Number of Subnets and Hosts

Planning Classless Routing

Planning Classless Noncontiguous Subnets

Using Route Summarization

Planning Variable Length Subnet Masks (VLSM)

Planning Supernetting and Classless Interdomain Routing

In network prefix length notation, the CIDR block is 220.78.168.0/21.

Choosing an Address Allocation Method

Choosing Public or Private Addresses

Network Address Translation

DHCP Integration with DNS and WINS

DHCP, APIPA, and IP Address Allocation

• Automatic allocation — APIPA. In the absence of a DHCP server, Automatic Private IP

Using a Perimeter Network

Implementing Secondary Paths

Using Load Balancing

Figure 1.13 Planning IP Multicasting

Planning MADCAP Servers

MADCAP Without DHCP

Planning IP Multicast-Enabled Routers

Configuring IP Multicast Scopes

Configuring Client Computers

Introducing IPv6 on Your Network

Figure 1.15 Introducing IPv6 on Your Network

• Automatic address configuration. IPv6 simplifies address configuration and renumbering by

Supported Features, Server Applications, and APIs

Supported IPv6 Tools

Planning IPv6 Addressing

IPv6 Address Types

Unicast IPv6 Addresses

Table 1.7 explains each field in a unicast global address.

Unicast site-local addresses

Unicast link-local addresses (FE80::/64)

Unicast unspecified address

Unicast 6to4 addresses (2002::/16)

Table 1.8 shows an example of each type of ISATAP address.

Multicast IPv6 Addresses

Multicast solicited node address

Anycast IPv6 Addresses

IPv6 Addresses Assigned to Hosts and Routers

• Multicast addresses (to listen for multicast traffic):

Routing IPv6 Traffic over an IPv4

Using 6to4 for IPv6 Traffic Between Subnets or Between Sites