Course Transcript

Microsoft Windows Server 2012 R2: Server

Infrastructure - DHCP Design
Designing a DHCP Solution
1. The DHCP Design Process

2. DHCP High-Availability Deployment Design

3. DHCPv6 Service Design and Implementation

4. DHCP Service Management Strategic Design

5. DHCP Database Management

6. Planning a DHCP Solution

The DHCP Design Process
Learning Objective
After completing this topic, you should be able to
◾ match tasks in the DHCP design process to the correct stage of the process

1. Introduction
Hi there, and welcome to Microsoft Windows Server 2012 R2: Server Infrastructure - DHCP
Design.

Jason Yates is your Microsoft Certified instructor for this course. Jason will be joined by Jacob
Moran later in this course.

[Jason Yates is a certified Microsoft instructor holding multiple Microsoft certifications including
MCSA (registered) Windows Server 2012; MCITP: Enterprise Desktop Administrator on
Windows 7; MCITP: Server Administrator on Windows Server 2008; MCITP: Enterprise
Desktop Support Technician on Vista; MCTS: Windows Server 2008 R2, Virtualization; MCTS:
Windows 7, Configuration; MCTS: Windows Server 2008, Active Directory; MCTS: Windows
Server 2008, Network Infrastructure; MCTS: Windows Vista, Configuration; MCSE (registered)
(2003, 2000, and NT); and MCSA (registered) (2003 and 2000). Jacob Moran is a certified
Microsoft instructor holding multiple Microsoft certifications including MCITP: Windows Server
2008 Server Administrator (registered) and Active; MCTS: Windows Server 2008 Application
Infrastructure (registered) and Network Infrastructure; MCITP: Enterprise Desktop Support
Technician on Windows 7 (registered); MCITP: SharePoint Server 2010 (registered); MCTS:
Microsoft SQL Server 2008 Implementation and Maintenance (registered) and Database
Administrator (registered); MCITP: SQL Server 2005 Database Administrator (registered);
MCTS: SQL Server 2005 (registered), MCTS: SharePoint server 2007 (registered) and
Windows SharePoint Services 3.0 (registered); MCTS: Windows Vista (registered) and
Windows 7 (registered); MCSE (registered) (2003, 2000, and NT 4.0); MCSA (registered)
(2003 and 2000); MCSA (registered) Windows Server 2012; MCDST (registered), MCDBA
(registered) (2000 and 7.0), MCT (registered); CCNA (registered), CCS (registered); and
CompTIA A+ (registered), Network+ (registered), Security+ (registered), and CTI+ (registered).
The course goal is to design and maintain a Dynamic Host Configuration Protocol (DHCP)
solution.]

Hi, I'm Jacob Moran, an MCT and MCSE in Windows Server 2012. And in this course, gang,
we're going to be focusing in on the ability that we have to manage our DHCP service
environment. You know DHCP is a core infrastructure service that is used to provide IP
addresses for clients, servers, and really anything that needs to gain an IP address, any other
node on our network.

So, as an administrator, I might think, "Okay, roll it out, life is good," but really, there is a lot of
important deployment questions to be considered in the design process. Is it a distributed or
centralized DHCP environment? Is there fault tolerance and high availability? Is it IPv4 or IPv6
or both?
Are we managing integration with services like DNS, Windows deployment services, network
access protection, all of which takes security authorization in order to cross from one world into
another? So we want to plan these things correctly so that we get the environment that we
expect.

2. DHCP solution design

What we have here is kind of a groundwork diagram. It's really describing kind of the core
functionality of DHCP. It's probably a review for most of you. Remember, the way DHCP works
is it has a pool of IP addresses, which we call a scope and it delivers those addresses to
clients who don't have an IP address but are advertising their need through a broadcast
basically, a discover packet. Now, what we want to focus in on here is how we can kind of
tailor DHCP to service the different types of clients and different configurations. And not only
can we create scopes, but we can also create things like exclusion ranges, reservations,
super-scopes. And we're going to be talking more about how we can address and tailor kind of
our delivery of IP addresses through the process of adding filters. Another important thing we
need to be thinking about is what other roles does DHCP need to advertise? So DHCP can
also be responsible for registering records in DNS on behalf of clients. It can also be
responsible for assisting in terms of discovery at WDS. There are some interoperability issues
there that we talked about in our WDS lesson. We might need to provide information about our
default gateways and we might need to provide networking information for different populations
of machines through the same DHCP server. So these are all things that we can kind of
control. Here what we're just looking at is, this is really meant to kind of anchor us into what is
the role DHCP has and how can we begin to kind of shape that IP address delivery.

[Heading: DHCP Design. A network consisting of an IP Access database, a DHCP server, and
three clients is displayed. The example shows the IP Access database connected to the DHCP
server. The DHCP server in turn delivers three IP addresses, 192.168.0.22, 192.168.0.13, and
192.168.0.77 to the three clients. The DHCP server also helps in identifying the default
gateway, DNS service, WDS service and WINS service. The DHCP team can create scopes,
exclusion ranges, address pools, reservations, leases, super-scopes, option types, and option
classes. Scope: A scope is the full consecutive range of possible IP addresses for a network.
Scopes typically define a single physical subnet on your network to which DHCP services are
offered. Scopes also provide the primary way for the server to manage distribution and
assignment of IP addresses and any related configuration parameters to clients on the
network. Exclusion range: An exclusion range is a limited sequence of IP addresses within a
scope, excluded from DHCP service offerings. Exclusion ranges assure that any addresses in
these ranges are not offered by the server to DHCP clients on your network. Address pool:
After you define a DHCP scope and apply exclusion ranges, the remaining addresses form the
available address pool within the scope. Pooled addresses are eligible for dynamic assignment
by the server to DHCP clients on your network. Reservation: You use a reservation to create a
permanent address lease assignment by the DHCP server. Reservations assure that a
specified hardware device on the subnet can always use the same IP address. Lease: A lease
is a length of time that a DHCP server specifies, during which a client computer can use an
assigned IP address. When a lease is made to a client, the lease is active. Before the lease
expires, the client typically needs to renew its address lease assignment with the server. A
lease becomes inactive when it expires or is deleted at the server. The duration for a lease
determines when it will expire and how often the client needs to renew it with the server.
Super-scope: A super-scope is an administrative grouping of scopes that can be used to
support multiple logical IP subnets on the same physical subnet. Super-scopes only contain a
list of member scopes or child scopes that can be activated together. Super-scopes are not
used to configure other details about scope usage. For configuring most properties used within
a super-scope, you need to configure member scope properties individually. Option types:
Option types are other client configuration parameters a DHCP server can assign when
serving leases to DHCP clients. For example, some commonly used options include IP
addresses for default gateways (routers), WINS servers, and DNS servers. Typically, these
option types are enabled and configured for each scope. The DHCP console also permits you
to configure default option types that are used by all scopes added and configured at the
server. Most options are predefined through RFC 2132, but you can use the DHCP console to
define and add custom option types if needed. Options class: An options class is a way for the
server to further manage option types provided to clients. When an options class is added to
the server, clients of that class can be provided class-specific option types for their
configuration. For Microsoft (registered) Windows (registered) 2000 and Windows XP, client
computers can also specify a class ID when communicating with the server. For earlier DHCP
clients that do not support the class ID process, the server can be configured with default
classes to use instead when placing clients in a class. Options classes can be of two types:
vendor classes and user classes.]

3. DHCP design process

All right, so here we have kind of a big picture. What are the things we should be thinking
about? What are some of the different stages in our design? So, for starters, Jacob, what are
some of the first few things we should be asking ourselves regarding DHCP? Where am I
going to use it, right? Not everything plays the DHCP game. Some of it doesn't even play
DHCP. It plays the Legacy BOOTP protocol. So I need to be aware of who my clients are,
where my clients are, and how they're going to be configured. I mean, that seems obvious first
and foremost, do I even need DHCP and if so where? But I really want to have an inventory in
my mind and written out of which of my services are going to be DHCP reliant and what kind of
information I expect to feed through DHCP. I mean, that's going to come into later on defining
the...knowing my different clients is going to define how long those clients should have a lease.
It's going to end up defining what options, right, that we just looked at in the previous slide,
right. Where is WDS? Where is DNS? Am I using WINS? If so, here is your WIN server, right.
The specific default gateways that are used for specific subnets. I need to know which scopes I
need to manage and where those scopes are going to be deployed. And Jason, I think that
really gets at the question of, you know, how many DHCP servers does it take to support a
specific scope? And I think I could answer, "Just one," but in terms of best practices, like so
many services, right, you don't want to just have one server because we've got other options.
Yeah, DHCP is going to be instrumental for every single network where I have got devices who
need that and I'm often going to have more than one network that needs to have, you know,
one of those DHCP servers and I have to decide how I'm going to service each one of those
different clients like you were talking about. You know, one of the questions I think is important
if we start thinking about the nitty-gritty now of our design and we've identified, okay, what
clients we need to actually have DHCP allocated to them. We need to come up with what kind
of configuration we actually need to do with those scopes. What, you know, even what kind of
IP addressing scheme that we're going to use? How I'm going to design those particular
scopes? I think another important question is DHCP availability. Jacob, what are some of my
options in terms of making sure that DHCP is available to all of those clients? Well, I mean,
you could just have an extra server lying around that you could install DHCP on, program it
with the right, you know, IP range, and you can get that up and going. And yet we're really
looking for more seamless business continuity when it comes to managing our IP space and
so with that, you've got the classic tried and true split-scope, right, two servers – you manage
some portion, I manage the other portion. You've got implementing a single DHCP service on
a cluster, so we're using Microsoft clustering, failover clustering, and active/passive situation
with regard to the service and we can provide failovers. So, if a server goes down, the other
server can take over the workload. We also have the DHCP's failover service, which can either
load balance or be in a standby mode and this can actually do the work of clustering without
requiring the clustering hardware and the localization that clustering usually requires, so it's a
great option. These are all based upon ideas that we're going to have another server available
to provide that service. And there's some preconfiguration that's been done. So, when it comes
crunch time, I've got this ability to failover. We're also thinking about the fact that in a...if I'm
going to be supporting a split-scope configuration or DHCP failover, where I've got multiple
scopes on multiple servers, but the ability to failover for each other in various ways. The
question comes, how does that DHCP discover packet end up getting connected to that
specific DHCP server, right? What are the methods that I have to get the client broadcast to
the DHCP server? Well, in small offices, many of which I've worked at, one of the things that
we would do is we create a single DHCP server. It'll be multihomed. It would have several
different adapters and it would have a connection to every single network, so it would be kind
of a, you know, playing a role right there in the middle. And that's, you know, that's useful with
a single DHCP server in a very small type of network, but there are other, in some ways, better
options than going that route. You can deploy multiple DHCP servers in those multiple, you
know, sites. Probably, the most common is going to be able to leverage the features that come
in your intermediate network devices, your routers, and your switches, to also kind of play that
role where they can either deliver IP addresses for you and you aren't looking at a Windows
DHCP server at all or you can configure them to forward those discover packets and that
interchange between client and DHCP server with, like IP helper agents or DHCP relay agents,
that's going to be, of course, an option. And there might be cases where you need to configure
a relay agent on Windows, like for instance, in a VPN type of situation, you know, so questions
for delivering IP addresses to remote clients that you're going to have to be concerned about
making sure, you know, is the remote, you know, ask the question I should say, is the remote
access server going to deliver those addresses or am I going to have that relayed from another
DHCP server through the remote access server? So I might have to configure my VPN server
to support that, so that's something I need to be aware of and include that as part of my plan.
So those are some of the basic options we have when we consider DHCP in multiple locations
and multiple subnets. How are we going to service them? You know, I can use one DHCP
server and then deliver that, you know, across multiple networks with the help of my routers
and switches, but that doesn't really address the question in terms of high availability and fault
tolerance if something goes wrong with that DHCP server. But DHCP is not the smartest
service in the box. So, if you have more than one DHCP server, but then, they don't really
synchronize with each other traditionally. Now, that changes in 2012 and that's something
we're going to be talking about in regards to multiple DHCP servers coming up.

[Heading: DHCP Design – The Design Process. The DHCP window is displayed. The DHCP
design consists of three stages. The first DHCP design stage is to determine the DHCP
service method. In the first DHCP design stage, the three most common address allocation
methods include the following options which can be combined in a hybrid deployment: 1.
manually configuring IP addresses at the client or device 2. allocating using the older BOOTP
protocol, and 3. automated DHCP allocation. The second DHCP design stage is to create a
DHCP design configuration. The two design options for static IP addressing are manually
configuring static addressing at the client and configuring DHCP and BOOTP reservations.
The two design options for DHCP scopes and dynamic allocation are lease duration and
configured DHCP options. The four design options for DHCP availability and fault tolerance are
split-scopes; DHCP service on a failover cluster; DHCP failover, which can be load sharing or
hot standby mode; and cold standby servers that are not high availability servers. The four
design options for DHCP on routed networks are to deploy multiple DHCP servers, configure
BOOTP or DHCP forwarding on routers, configure BOOTP or DHCP relay agents, and
configure multihomed DHCP servers. The two design options for DHCP policy are scope-level
targeting and server-level targeting. The design options for network access security and
control are link-level or MAC filtering server-level or scope-level targeting and user or vendor
classes. The third DHCP design stage consists of mapping the design configuration to the
existing hardware and testing before deployment. In the third DHCP design stage, the
considerations that must be factored into the general design process include DHCP hardware
requirements, DHCP scalability, DHCP manageability, DHCP performance, DHCP
consolidation, DHCP interoperability, DNS update configuration, NAP interoperation, and
Active Directory registration.]
DHCP High-Availability Deployment Design
Learning Objective
After completing this topic, you should be able to
◾ describe high-availability options for DHCP design and deployment

1. DHCP high-availability service options

So let's talk now specifically about some of the changes in Windows Server 2012 DHCP and
talk about our high-availability options. Now, if you consider the problem that Jacob presented
and that is we've got multiple locations, how do we service all of those clients in those multiple
locations? Well, we can consider, well, do we put more than one DHCP server out there and if
we do, how do we ensure that if one server is no longer available that we can still service the
rest of our network? Traditionally, we can do things like split-scopes, we can use service
clusters, and then now, with Server 2012, we can use a new feature called failover or the load-
balancing mode to actually ensure that DHCP is available. Now, there's pros and cons to each
one of these and we want to speak to the pros and cons as we show you how to configure
them, so let's have a look.

[Heading: DHCP Service High Availability – Options. The three DHCP service high availability
options are split-scopes, service cluster, and DHCP failover.]

2. Deploying DHCP split-scopes

So the first of the three models that we have to look at here is what we call the DHCP split-
scope and, you know, this is the easiest to understand fundamentally. If you understand that in
a particular scope, you identify a subnet, but then you enumerate the available IP addresses in
that subnet that a particular server is willing to hand out and which of those IP addresses are
excluded from being able to be handed out. And this is actually a technology that you could
implement even with a non-Microsoft server as the other DHCP server. You're simply saying
there is a pool of addresses, I'm going to handle a certain number, maybe it's 1 through a 100
and the other server is going to handle 101 through 200, right. And then the rest are assigned
for static IP addresses, so, I mean, one of the pros of this is it's extremely backwards
compatible, it's extremely flexible and heterogeneous, and if it is an all-Microsoft solution with
Server 2012, it can be automated pretty easily. Jason, what else do you think of in terms of this
or what are some of the cons of using the split-scope? Well, one the big problems with split-
scope is you have often kind of the textbook implementation of this, a DHCP server on the
other side of a router and that other DHCP server has a 20%, or that, you know, small batch of
addresses, just in case, the just in case pool of addresses in the event the primary DHCP
server goes down. So we call it the 80-20 split and that's kind of a typical kind of configuration.
The problem is that a single DHCP server generally is going to exceed an 80% threshold. In
other words, it's usually going to, if you look at the range of addresses, there's a huge rate of
need for IP addresses and so 80%, you're going to reach that saturation point and so that
means you're going to be pooling addresses across that remote, you know, that router from
that other server. So what you're saying is that 20% is going to be utilized, not in a failover
situation, but in the normal course of business, right? We're using that and then once a client
gets connected to that remote DHCP server, that becomes their best friend, right. That's what
they keep renewing their IP address against. Exactly and actually that kind of stickiness to an
IP address with the DHCP server can be a problem not only because it will associate and have
an affinity for that remote DHCP server, but there is a time, there is a time gap here, so let's
say you've got a DHCP server. Even in the primary slides available, client gets an address and
that server then goes down, so the net client continues to hunt for a period of time and try to
talk to that primary DHCP server to renew that address. Then when it gives up, then it's going
to finally resort to looking for that remote DHCP server, builds an affinity with that server if
there's networking problems and it can't reach that server later on and the primary is back up,
we go through the same process again. All the while, the user's complaining about how slow
the Internet is and those firewall guys are messing it up again. So there is this gap in terms of
time, it's not the most responsive when you have the transitionary situation going between
those two DHCP servers. And the issue is the DHCP server with the split-scope configuration
is highly compatible, but it's not very intelligent. Jason, one of the things that I do like about the
all-Microsoft implementation of this is that we do now have the ability to configure a delay
between the host DHCP server and a secondary split-scope DHCP server that's in a remote
location indicating that if, you know, I mean, who is to say, sometimes a DHCP server is busier
processing than it is in terms of the delay, in terms of network traffic and, again, you might dip
into that 20% remote server, not because of saturation, not because of failover, but just
because the first server was busier, the second server was more idle and, again, you end up
with that sticky situation of being connected to the remote server, delaying and exacerbating
this process, but at least the delay can help to ensure that we tend to prefer the localized
server, again, unless it's a failover or a saturation point, but I think both of those are reasons
why unless that if we have 2012 or if we have a cluster I should say, we may well want to look
at implementing this as using a different technology.

[Heading: DHCP High Availability – Split-scopes. In a 80-20 split-scope configuration, 80% of

the IP addresses are handled by the local DHCP server and 20% by the remote DHCP server.
In a 50-50 split-scope configuration, 50% of the IP addresses are handled by the local DHCP
server and the other 50% are handled by another local DHCP server. The DHCP window is
displayed. Running along the top of the window are the File, Action, View, and Help menus.
Below the menu bar is the tool bar with various buttons such as the Back and Forward buttons.
Below the tool bar, the window is divided into two areas. The area to the left consists of a
directory structure with nodes and subnodes and the area to the right shows information about
the node or subnode that is selected in the area to the left. In the area to the left, the shortcut
menu for one of the subnodes is displayed. In the shortcut menu, the Split-scope shortcut
submenu option is highlighted. Then two pages of the Dhcp Split-Scope Configuration Wizard
are displayed. Then the Exam Tip is shown. The text in the Exam Tip reads, "Know how to
place scopes to IP addresses that are both local and remote."]

3. Deploying a DHCP service cluster

Okay, so that brings up a good point. In order to address that split-scope cons, what we can
resort to using is a cluster. Now, really what we're doing is we're adding an additional level of
intelligence to the DHCP service. DHCP is unaware of this. This is not a DHCP-specific
clustering service. We're using clustering in order to actually provide that kind of failover
experience, kind of that rapid redundancy, if you will, but the problem with clustering is, well,
clustering. What are some of the challenges with clustering, Jacob? Well, there is a lot of
configuration on the hardware front end that goes into this, right. I mean, we're going to have a
shared heartbeat network. We're going to have to have a shared connection to a shared data
storage, which might be localized storage or, you know, direct access or it might be something
like a storage area network or an iSCSI connection it will have to be established to. And really,
what we're describing in this situation is there is a single virtual server that can host the scopes
that we need, but one of our two or more servers that are participating in this cluster is
responding the client request across all of the different subnets. So I have a 100% availability
of those IP addresses. We don't have the issue of some of the IP addresses being handed out
by one server and some being handed out by another. They're all being handed out by the
active node. It's using its memory space, it's writing its work back to the shared storage, but
that means that passive node, as far as DHCP is concerned, is sitting there like a lump on a
log doing nothing, so this means that we are not doing any load balancing in this process, we
are providing high availability and it's a different goal. This really handles the need for high
availability for our enterprise environment. If I am providing the redirection, the maybe relay
agents and things like that from remote subnets and those redirection identifiers are pointing to
the DHCP virtual IP address, the cluster IP address, then it will be handled by whichever
server is up and running and even if I bring the server down for maintenance or if it goes down
because of a bad fan or motherboard or something like that, the passive node can kick in,
adopt the virtual IP address, dig into the shared storage, and respond. But I think that's the key
thing to remember is that there is a lot of infrastructure you have to put in, in the first place.
You install DHCP into the cluster rather than as a localized tool and that all or nothing aspect
of DHCP is not always what we want, right. I mean it works, but it means that, that's a 100%
responsibility on one specific server. The other server is just in a very passive mode.

[Heading: DHCP High Availability – DHCP Cluster Deployment. The text in the slide reads
"What are the weakest points of a cluster?" Below the text, an example of a failover cluster is
displayed. In the example, a failover cluster is implemented on a network. The network
consists of a shared storage that is connected through active and passive nodes to two DHCP
servers. The two DHCP servers in turn provide DHCP virtual IP addresses to four clients. ]

4. Deploying a DHCP failover

And so, you know, we've had some strengths and some weaknesses, some pros and cons
with a split-scope configuration, with a cluster-based configuration in terms of handling local
and remote, in terms of providing high availability. What really seems to be a best possible
scenario I'd say for a lot of customers really is the DHCP high-availability options and the
DHCP load-balancing options that are a part of server 2012. We're looking here at the idea of
hot standby mode and Jason, you know, I'm seeing we've got five DHCP servers pictured
here, central site and four peripheral sites, and this is a standby operation. How would
someone designing this be looking at the layout and the topology when using a hot standby
failover deployment? I really like this for branch offices because it's going to enable that
failover experience because now what we have with server 2012 is we have intelligence added
to DHCP. So, in answer to your question, what are some of the things we're going to be
thinking about is one of the things we want to be aware of is in this hub and spoke type of
model. We're creating what we do we call kind of those active/passive relationships with that
hot standby mode, we need to identify who, what servers we're going to choose to be the
failover servers. Now, the primary site servers that you have listed in this diagram versus the
centralized servers, there is going to be, of course, the ones that are going to deliver most of
the IP addresses except in the case of failover. So hot standby mode is really ideal for multisite
situations like you have here, but it's not limited to multisite situations. Certainly in this kind of
configuration, when you have a primary site server go down, the centralized server can pick it
up. Now, what makes this different from split-scopes is the fact that both the primary DHCP
server and that central DHCP server have actually talked to each other. They're aware of each
other's address pools. So that primary site server actually is responsible for not 80% of the
scope, a 100% of the scope in addresses unless it's not available in which case that central
site server, again, is aware of how many addresses are remaining and that are free in the pool.
It can then pick up where that primary site server left off. And so that kind of intelligence makes
for a much more simplified kind of approach to failover compared to the cluster and much more
manageable and responsive than what you get with the traditional split-scope. You know,
Jason, the only thing I wanted to ask, you know, with regard to this picture that someone might
be seeing, they might be thinking, okay, so I've got this client, they sent out a broadcast, they
were able to communicate with the local server. Now, the server is down, another new client
sends out their discovery broadcast. So does that mean that, that second client who needed to
get an IP address in that circumstance would be relying on a DHCP relay agent to still forward
that broadcast over to the central site? Well, certainly, communication still has to exist between
the primary site and the central site. So really what we're talking about is what happens if that
primary DHCP server goes down and so the intermediate networking devices still need to be
able to forward those DHCP broadcast so that, that central server, the failover server, can pick
up the load. Now, one of the things to consider when you're designing this is how you want that
transition to work between when the actual primary server goes down and that central server
picks up the load. See, the two are in communication, however, if that primary site server goes
down, there is going to still be a delay from the time the central server detects that it's down
and if clients are sending IP lease request and lease renewals to the failover server, then you
have to configure how that failover server is going to respond during that transition period
when it…before it, you know, it totally determines that the primary server is down, what they
call a partner down state. So the way it figures that out is a reservation. So, as a designer, you
actually can set up a reservation percentage on the failover server so it has something to work
with until it knows its partner is completely down. So, when those…suddenly it's bombarded
with new lease requests, it has a few addresses it can pass out, then when it determines that
the partner is down in a period of time at that transition time out. Then it can resume the rest of
the address pool and service all of the clients in that location.

[Heading: DHCP High Availability – DHCP Failover Deployment Modes (Hot Standby Mode). A
hub and spoke model of the hot standby mode is displayed. The model consists of four primary
sites – primary site1, primary site 2, primary site 3, and primary site 4. The four primary sites
are connected to a central site. Primary site 1's address pool is 10.0.0.0/16, primary site 2's
address pool is 20.0.0.0/16, primary site 3's address pool is 30.0.0.0/16, and primary site 4's
address pool is 40.0.0.0/16. The central site acts as the secondary backup site for all the
primary sites and is aware of all their address pools. The hot standby mode of operation is best
suited to centralized backup scenarios where the secondary backup DHCP service acts as a
failover to the primary local DHCP services at the remote offices and sites.]

All right, so we've been focusing on this idea of the implementation of the DHCP failover in that
hot standby mode, right. You see that works great for the local remote communication to work
well. We're failing over to the side on an as-need basis, but there is also this idea of wouldn't it
be great to have two DHCP servers that could coordinate their activities. I mean, now that we
have DHCP servers that are actually talking to each other, sharing their information, why not
have the ability to have a pair of DHCP servers that provide load balancing for each other so
that the clients could connect to either of the two servers? And, if an IP address has been
handed out to a particular client, the other DHCP server already knows, learns that
information, and doesn't hand out that same IP address because it's aware of this process has
already gone on. And so we have different subnets that can all be managed, and so this is a
50-50 split, right, rather than a 100-0. In terms of workload, we're actually looking at dividing
the workload up, managing the same scope, the same pool of addresses, the same
reservations, and filters, and polices, and everything else that we would have in place to
support those same subnets. So this is a very cool configuration. Again, as we look at
implementing this, we have that benefit of server 2012 actually sharing what it knows and
having that communication protocol giving us a better solution. Now, this is not really designed
for a local remote situation. We want that information to be delivered fast and furious and be
able to support essentially, you know, multiple servers providing the solution, but unlike, say,
having two servers supported in the cluster, as we said, it is not active/passive, it's 50-50 split,
it's actually load balancing, and it does not require a whole set of additional hardware and
communication to be there in the first place. Any other thoughts about the load-balancing
mode, Jason? I think it's interesting how it works in that both machines are running an
algorithm. They're receiving requests from the same devices and yet what they do is they look
at the MAC address and they calculate it and based on how you split the addresses up, it runs
an algorithm and says, this is the first half of this MAC address range, you know, 1 through 128
or however that works and then 129 through 256. If we're doing 50-50, the other server will
respond to MAC addresses that yield...that result in the algorithm. So they use a little bit of
math in order to determine who is doing what. And as the designer, one of the things you can
determine is, hey, I want that particular DHCP server really to do most of the work, because it
has, you know, for whatever reason, maybe it doesn't have other competing roles on it, so you
wanted to dedicate that server more for the network, but you still wanted some load balancing
in place where you can actually change it from not 50-50 but from 60-40 and that tweaks the
algorithm in such where now it's 40% of those requests that are coming in, the other DHCP
server will take versus the other one. So there are some tweaking you can do in regards to
kind of the weight and balance between the two load balancers. But, as you were saying,
Jacob, this is a really easy solution to implement for single-site locations, so you have high
response when clients are asking for DHCP, you know, IP addresses. Great for mixed
environments where I've got phones, mobile devices, wireless clients, and desktops and
servers and printers, and so forth. They're all looking for IP addresses. This gives us an
opportunity to create an array of servers that can respond to those requests when they come
in.

[Heading: DHCP High Availability – DHCP Failover Deployment Modes (Load Balancing
Mode). The load sharing mode of operation is best suited to deployments where both servers
in a failover relationship are located at the same physical site. The DHCP services handle
DHCP client requests based on the administrator-configured load distribution ratio. In the
example, two DHCP servers act as load balancing pair for each other. The two DHCP servers
are connected to DHCP relay agents and subnets.]

5. Demo: DHCP failover

All right gang, let's take a look at DHCP failover, shall we? DHCP failover, as you recall, is all
about being able to provide multiple DHCP servers working in tandem with each other. And as
we can see here, I've got a DHCP server. There is a scope that's been built out. We've got a
range of a 100 addresses. We got some leases already in place. Just for fun, let's go ahead
and make one of those, let's say, for the SQL server. Let's go ahead and make that a
reservation so it will stick. All right, so we've got some good things in place and some Scope
Options that have been defined. I wanted multiple servers to work with this content so that
there is the opportunity for multiple servers to respond to clients that if one server goes down,
no worries, I've got another waiting in the wings.

[The DHCP window is displayed. Running along the top of the window are the File, Action,
View, and Help menus. Below the menu bar is the tool bar containing buttons such as the
Back and Forward buttons. Below the tool bar, the window is divided into two areas. The area
to the left consists of a directory structure with nodes and subnodes and the area to the right
shows information about the node or subnode that is selected in the area to the left. The main
node in the area to the left is the DHCP node. This node has two subnodes –
corpapp1.corp.brocadero.com and CORPDC1.corp.brocadero.com. The
corpapp1.corp.brocadero.com subnode has two subnodes – IPv4 and IPv6. The
CORPDC1.corp.brocadero.com subnode has two subnodes – IPv4 and IPv6. Under the
CORPDC1.corp.brocadero.com subnode, the IPv4 subnode is expanded and has several
subnodes such as the Scope [10.0.0.0] Corp.brocadero.com LAN subnode. The Scope
[10.0.0.0] Corp.brocadero.com LAN subnode again has several subnodes such as the Address
Pool subnode, the Address Leases subnode, the Reservations subnode, the Scope Options
subnode, and the Policies subnode. In the area to the left, the Address Leases subnode is
selected and information about the subnode is displayed in the area to the right. The instructor
then clicks the Scope [10.0.0.0] Corp.brocadero.com LAN subnode in the area to the left and
the area to right shows information about the subnode. Then the instructor clicks the Address
Pool subnode in the area to the left and information about the Address Pool subnode is
displayed in the area to the right. Then the instructor clicks the Address Leases subnode in the
area to the left and information about the Address Leases subnode is displayed in the area to
the right. The area to the right now shows a table with four columns and three rows. The four
headers in the table are Client IP Address, Name, Lease Expiration, and Type. In the first row,
the entry under the Client IP Address header is 10.0.0.100. In the second row, the entry under
the Client IP Address header is 10.0.0.101. In the third row, the entry under the Client IP
Address header is 10.0.0.102. The instructor right-clicks the 10.0.0.101 entry in the second
row to display the shortcut menu. The shortcut menu has five shortcut menu options – Add to
Filter, Add to Reservation, Delete, Refresh, and Help. The instructor selects the Add to
Reservation shortcut menu option and the DHCP pop-up box appears. The standard text in the
DHCP pop-up box reads, "Lease converted successfully to reservation." Below the standard
text is the Close button. The instructor clicks the Close button to close the DHCP pop-up box.
In the area to the left, the Reservations subnode now contains the [10.0.0.101]
CORPSQL08R2 subnode. In the area to the left, the instructor clicks the Scope Options
subnode and information about the Scope Options subnode is displayed in the area to the
right. The table in the area to the right now consists of three rows and four columns. The four
headers in the table are Option Name, Vendor, Value, and Policy Name. In the first row, the
entry under the Option Name header is 003 Router, the entry under the Vendor header is
Standard, the entry under the Value header is 10.0.0.1, and the entry under the Policy Name
header is None. In the second row, the entry under the Option Name header is 006 DNS
Servers, the entry under the Vendor header is Standard, the entry under the Value header is
10.0.0.200, and the entry under the Policy Name header is None. In the third row, the entry
under the Option Name header is 015 DNS Domain Name, the entry under the Vendor header
is Standard, the entry under the Value header is corp.brocadero.com, and the entry under the
Policy Name header is None.]
Well, to make that happen, I've got a couple of options, right. We could go in and we could
decide that we want to use a Split-Scope. We've even got a split-scope wizard, we don't have
to do this manually. Both servers maintain the scope, but have an exclusion for the IP
addresses that the other server is going to hand out. That's okay, but there's no
communication, there is no indication of failover. There is just two servers that happen to only
support a certain portion of it. And we can end up with some challenges in supporting that
because there's no usage of the full bandwidth. We could install in a cluster and have the
whole scope available with a couple of cluster nodes. But, of course, that requires that I
configure clustering, which is definitely some extra work on the front end. Not necessarily the
easiest thing to do for wide area network solutions either. Or 2012 allows us to configure the
failover solution.

[The DHCP window is displayed. In the area to the left, the instructor right-clicks the Scope
[10.0.0.0] Corp.brocadero.com LAN subnode to display the shortcut menu. The shortcut menu
has nine menu options – Display Statistics, Advanced, Configure Failover, Reconcile,
Deactivate, Delete, Refresh, Properties, and Help. The instructor selects the Advanced
shortcut menu option to display the Split-Scope submenu option. The instructor points to the
Split-Scope submenu option. Then the instructor points to the Configure Failover menu option.]

So that's what we're going to do here – Configure Failover for two servers that actually talk to
each other for the DHCP service. We're going to indicate the partner server in this case, which
I've already added to the console for speed and when we go into this environment, it says, "All
right, what do want to define as a Relationship Name?" So I'm going to name this the CORPDC
- CORPAPP1. It's just what it had before just with the fully qualified domain names. The
Maximum Client Lead Time, remember, that refers to essentially how much time can a DHCP
server give to a client on renewal if the primary server is offline. What Mode are we in? Is it
Load balance with a 50-50 split here or is it a Hot standby solution where one server is
providing all the work and, typically, there is a remote server that it'll be able to jump in if that
main server goes offline for any period of time.

[The DHCP window is displayed. In the area to the left, the shortcut menu of the Scope
[10.0.0.0] Corp.brocadero.com LAN subnode is displayed. The instructor selects the Configure
Failover menu option and the first page of the Configure Failover wizard appears. The first
page has the Available scopes section with one entry 10.0.0.0 and the Select all checkbox.
The Back, Next, and Cancel buttons are at the bottom of the wizard. The instructor clicks the
Next button and the second page of the wizard opens. The second page has the Partner
Server drop-down list box, the Add Server button, and the Reuse existing failover relationships
configured with this server (if any exist) checkbox. The instructor clicks the down-pointing
arrow of the drop-down list box to reveal the corpapp1.corp.brocadero.com drop-down list box
option. The instructor then clicks the corpapp1.corp.brocadero.com drop-down list box option.
The instructor then clicks the Next button and the third page of the wizard opens. The third
page has the Relationship Name text box, the Maximum Client Lead Time spin boxes with the
default value of 1 in hours and 0 in minutes, and the Mode drop-down list box with the default
value of Load Balance. Below the Mode drop-down list box is the Load Balance Percentage
section which contains the Load Server and the Partner Server spin boxes in percentage. The
entry in the Local Server spin box and the Partner Server spin box is 50. Below the Partner
Server spin box is the State Switchover Interval checkbox. Next to the State Switchover
Interval checkbox is a spin box with the default value of 60 in minutes. Below the State
Switchover Interval checkbox is the Enable Message Authentication checkbox and the Shared
Secret text box. The instructor types CORPDC – CORPAPP1 in the Relationship Name text
box. Then the instructor points to the Maximum Client Lead Time spin boxes in hours and
minutes. Next the instructor displays the drop-down list options in the Mode drop-down list box.
The two drop-down list box options are Load balance and Hot standby. The instructor selects
the Hot standby drop-down list box option and the Load Balance Percentage section is
replaced with the Hot Standby Configuration section. The Hot Standby Configuration section
has the Role of Partner Server drop-down list box and the Addresses reserved for standby
server spin box in percentage. The entry in the Role of Partner Server drop-down list box is
Standby and the entry in the Addresses reserved for standby server spin box is 5.]

Again remember, it will be able to go offline, but this is not like a split-scope because although
5% of the addresses are reserved for the standby server. Again, the main server when it come
back online is going to learn about those and be able to respond to those leases and
participate in conjunction with that client when necessary. Then we have the State Switchover
Interval, which says, okay, if we have a standby server, for example, or even in a load balance
situation, one server that goes offline when that client comes back online, do we fail the client
over to the first server? If so, after how long when that server is up and running? And then
what kind of network communication is going to be used to ensure this relationship has
integrity. Is there no authentication? They simply say, "Hey, it's me, the one with this
relationship name for this scope. Let's go ahead and share what we know." Or is there
essentially a Shared Secret that's encrypted with SHA 256-bit encryption to protect that
relationship so there is no intrusion, no rogue, man-in-the-middle, or anything of that nature.

[The third page of the Configure Failover wizard is displayed. The instructor points to the
Addresses reserved for standby server in percentage spin box. The instructor then points to
the State Switchover Interval checkbox. Then the instructor selects the Load balance drop-
down list box option in the Mode drop-down list box and then selects the State Switchover
Interval checkbox. The instructor then unchecks the Enable Message Authentication checkbox
and the Shared Secret text box is grayed out. The instructor then checks the Enabled
Message Authentication checkbox and the Shared Secret text box is no longer grayed out. In
the Shared Secret text box, the instructor types in the password and points to the Next button.]

So that's a good idea. It's why it's the default. We're going to enable this with a 50-50
relationship. It configures that and if we head over here to corpapp1 and refresh. Hey, look, we
just got a scope and so, if we take a look at this scope, we can see that it consists of the same
exact pool of addresses and it already has the leases. Now, if we were looking at a split-scope,
it wouldn't maintain the same leases, right, one server has one set of leases, the other server
has another, but this is a failover or, in this case, load balance relationship that supports
failover that supports either server participating with these components so they have the exact
batch. All the options, all the reservations, and the live list of leases shared between the two.

[The third page of the Configure Failover wizard is displayed. The instructor clicks the Next
button and the last page of the wizard appears. The instructor clicks the Finish button at the
bottom of the wizard and the Configure Failover dialog box appears. The Configure Failover
dialog box states that the configure failover was successful. Then the instructor clicks the
Close button to close the dialog box and the DHCP window is again displayed. In the area to
the left, under the corpapp1.corp.brocadero.com subnode, the instructor points to the IPv4
subnode. The instructor refreshes the computer and the IPv4 subnode now has the Scope
[10.0.0.0] Corp.brocadero.com LAN subnode. The instructor clicks the Scope [10.0.0.0]
Corp.brocadero.com LAN subnode and the area to the right shows information about the
subnode. The area to the right now has a table with one header and five rows of entries. The
header is Contents of Scope and the five entries are the Address Pool, Address Leases,
Reservations, Scope Options, and Policies folders. The instructor clicks the Address Pool
folder to open it. The Address Pool folder consists of a table with three headers and one row of
entry under each header. The instructor then clicks the Address Leases subnode in the area to
the left and information about the subnode is displayed in the area to the right. The instructor
then navigates to the CORPDC1.corp.brocadero.com subnode and points to the [10.0.0.101]
CORPSQL08R2.corp.brocadero.com subnode under the Reservations subnode. Then the
instructor navigates to the corpapp1.corp.brocadero.com subnode and points to the
[10.0.0.101] CORPSQL08R2.com.brocadero.com subnode under the Reservations subnode.
The IPv4 subnode under the corpapp1.corp.brocadero.com subnode is now an exact match of
the IPv4 subnode under the CORPDC1.corp.brocadero.com subnode.]

Now, for continued maintenance, remember that we can come in here and we can replicate
the relationship. Again, if we make a change to configuration, we can ensure that's consistent
between the two. If we want to, we can come in here and replicate the scope. Again, enforcing
the scope configuration and content, the IP address range reservations. And we can come in
here and disconfigure the failover essentially. Setting those up to be isolated scopes if we
should so choose. So those are the options that we have available for us when it comes to
configuring failover in DHCP.

[The DHCP window is displayed. In the area to the left, the instructor navigates to the
CORPDC1.corp.brocadero.com subnode and right-clicks the Scope [10.0.0.0]
Corp.brocadero.com LAN subnode to open the shortcut menu. The instructor selects the
Replicate relationship shortcut menu option to display the DHCP dialog box. The standard text
in the dialog box reads, "This action will replicate the configuration of all failover scopes that
are part of the failover relationship CORPDC – CORPAPP1 to the partner server
corpapp1.corp.brocadero.com. This operation may take some time." Below the standard text
are the OK and Cancel buttons. The instructor clicks the OK button to close the dialog box and
the Failover Scope Configuration Replication dialog box appears. The instructor then clicks the
Close button to close the dialog box. The DHCP window is again displayed. In the area to the
left, the instructor navigates to the CORPDC1.corp.brocadero.com subnode and right-clicks
the Scope [10.0.0.0] Corp.brocadero.com LAN subnode to open the shortcut menu. The
instructor selects the Replicate Scope shortcut menu option to open the Failover Scope
Configuration Replication dialog box. The instructor clicks the Close button to close the dialog
box. The DHCP window is again displayed. In the area to the left, the instructor navigates to
the CORPDC1.corp.brocadero.com subnode and right-clicks the Scope [10.0.0.0]
Corp.brocadero.com LAN subnode to open the shortcut menu. The instructor points to the
Deconfigure Failover shortcut menu option and then closes the shortcut menu.]
DHCPv6 Service Design and Implementation
Learning Objectives
After completing this topic, you should be able to
◾ match each DHCPv6 configuration option to its correct description
◾ sequence the stages in the DHCPv6 message exchange

1. DHCPv6 service design and implementation

I'm sure you're all well acquainted with IPv4 addressing and the delivery of v4 addresses
through DHCP, but today, we are talking about IPv6 and I say we, meaning the whole world.
V6 is something that is on many people's minds as a way to transition from v4 to a new
generation, the next generation IP standard, and Microsoft's Windows Server 2012 and 2012
R2, well, it can provide a DHCP version 6 service just like it does with version 4. There are
differences because, well, version 6 addresses are very different from version 4 addresses in
terms of how they're allocated and maintained and how they're structured and so forth. And
Jacob, I've got a question for you though. If we're going to choose IPv6 in our network, do we
even really need a DHCP version 6 server? Well, I think you can answer that to some degree
in a way that's similar to what we would say with IPv4, do I have to have a DHCP version 4
configuration in my network? No, I don't have to have it. Is my administrative burden greatly
reduced by implementing it? Sure, right, when it comes to making sure that I don't have
duplicate IP addresses, ensuring that I have the correct options configured appropriately for
each subnet of IP addresses that I'm working with, yeah, it's going to be addictive, right. Once
you start using it, you don't want to quit. But the important thing to recognize is that it is a new
infrastructure, right. We're dealing with these 128-bit addresses, even more of a reason not to
try and implement these manually, right. So we've got IPv6 clients and these IPv6 clients then
can be supported with a DHCP version 6 service to dynamically hand out those addresses.
And notice that as we look here, if we're trying to implement this across remote subnets, that
means we need a DHCP version 6 supporting relay agent, right. A relay agent that knows how
to point to a DHCPv6 address for the purposes of forwarding that message to remote subnets.
We'll talk about what protocols are in play and how this process occurs with DHCP version 6.
Let's walk through some of the elements of it and make sure that this is in place because,
typically, most folks have had an opportunity to look at an IPv6 address before, but not
necessarily to see the nuances of the various different types of addresses and how they
actually coordinate together for the purpose of giving you a DHCP version 6 address.

[Heading: DHCPv6 – Service Design. The example shows DHCPv6 clients in two subnets,
DHCPv6 subnet 1 and DHCPv6 subnet 2. The DHCPv6 clients in subnet 2 are supported by
DHCP version 6 service and can use the DHCPv6 relay agent to dynamically hand out IP
addresses to the remote subnets in DHCPv6 subnet 1.]

2. Types of interface address configuration

As we take a quick look at this picture here showing us an IPv6 manually assigned address, of
course, the first thing that most people think is, wow, I hope I don't have to type that. Rarely
are we going to need to implement an IPv6 address using a static configuration. We try and
avoid it whenever possible simply because it is rather long. They're hexadecimal. There's a lot
of places to go wrong, right. How many bits does it take to get to the center of an IPv6
address, well, 64, 64 bits to get to that. When you're at the center, it's important to remember
that 64th bit is the absolute dividing point between the network portion and the host portion of
an IPv6 address, so the last half is always the host. You always have 64 bits identifying the
host. Now, the first 64 bits, when we're talking about IPv6 addresses, remember, reflect a
network ID. But, when you're dealing with public IPv6 addresses, one of the things that you're
going to notice is actually only the first 48 bits are going to be assigned as a specific network
address and then you have the next 16 bits, right, from 48 to 63, to identify the actual subnet
that you might be operating on. So those aren't going to be handed out by an ISP. You, as an
administrator, have the flexibility to subdivide your network into these smaller portions, so we
can see that definition there. Notice when we look at the subnet prefix length assigned to a
host, this is very typical, the host assumes left-half network, right-half host. You typically are
only going to see shorter prefixes, for example, on routers where you might be routing entire
blocks of subnets all in one direction or another, okay. Notice again, we have the DNS server
here as well. Pointing to that in this case is pointing to itself for DNS, that's fine and you'll
notice, of course, that the IPv6 address in the screenshot is much shorter than the same IPv6
address that's down at the bottom. Remember you have the ability to drop leading zeros and
multiple subnets of zeros, shorthand notation, if you will, just to simplify this process. So take
advantage of that to make it easier when you are ever having to enter in these IP addresses.
And when it comes to a manual configuration, you'll notice that, again, there is no sense in
necessarily coming up with the most difficult, obscure 64 bits you can come up with. In this
case, we have 1000. That's pretty easy to remember, all right, and that's what you're looking
for, something that will be easy for you to use just like it is in IPv4 environment. When you
have static IP addresses, keep the burden simple for yourself. So we're going to move from
our static configuration here and start talking about our dynamic options.

[Heading: DHCP DHCPv6 – DHCPv6 Client IPv6: Manual Configuration. The General tabbed
page of the Internet Protocol Version 6 (TCP/IPv6) Properties dialog box is displayed. The
tabbed page has the Obtain an IPv6 address automatically and the Use the following IPv6
address radio buttons. The Use the following IPv6 address radio button is selected. Below the
Use the following IPv6 address radio button are the IPv6 address, the Subnet prefix length,
and the Default gateway text boxes. The entry in the IPv6 address text box is 2001:db8::1000
and the entry in the Subnet prefix length text box is 64. There is no entry in the Default
gateway text box. Below the Default gateway text box are the Obtain DNS server address
automatically and Use the following DNS server addresses radio buttons. The Obtain DNS
server address automatically radio button is grayed out. The Use the following DNS server
addresses radio button is selected. Below the DNS server addresses radio button are the
Preferred DNS server and the Alternate DNS server text boxes. The entry in the Preferred
DNS server is 2001:db8::1000. There is no entry in the Alternate DNS server text box. An
example of an IPv6 manually assigned address is also displayed. The address is
2001:0db8:0000:0000:0000:0000:1000. The network ID portion of the IPv6 manually assigned
address is 2001:0db8:0000, the subnet portion is 0000, and the host portion is
0000:0000:0000:1000.]

Now, Jason, one of the first things that anyone who encounters IPv6 on a Windows 7 machine,
or Server 2012, or Windows 8. One of the things they see is what's known as this link-local
IPv6 address. Again, if we're just trying to provide a framework for this, this is a dynamically
assigned address, isn't it? Yes, and it's very different than IPv4. First time you type this in,
you're looking at it, and you've never seen these kinds of addresses before. You're thinking,
well, what's with all these letters? Why is it so large? What's going on here? And the new IPv6
is hexadecimal, is presented very differently. Jacob described a little bit of the characteristics.
But here is something else that's unique about it and that is you automatically receive an
address whether using DHCP or not. Here is the thing with link-local addresses. The link-local
address is very similar to the APIPA address, the Automatic Private IP Address
autoconfiguration that was around since, I don't know, Windows 2000, Windows 98. I think the
idea with that is that 169.254 address. If you can't get a legitimate address from a server, then
your machine makes one up, right. That 169.254 version 4 address. This is not the equivalent
to that. It is in the sense that is autoconfigured, but this particular address is more significant.
You want to be thinking differently in regards to v6. You want to realize that devices in a v6
world are going to have more than one address. In IPv4, assigning more than one address
unnecessarily to devices would be paramount to scandal because we're such a short supply of
IPv4 addresses. Imagine if every device on your network had two IPv4 addresses or three
IPv4 addresses, your pool would shrink, you know, dramatically. With v6, the notion of
assigning multiple addresses is not as scary as it sounds because there are so many
addresses available – the 128 bits available. It's a monstrous amount and just in terms of the
host value, in terms of how many addresses that you can distribute, so every device has its
own link-local address. Now, this address is important because it uses this address to actually
communicate to other v6 devices, even communicating to DHCP and identifying its neighbors
and its routers so that it can retrieve, maybe, additional addresses so it has global routing
capability.

[Heading: DHCP DHCPv6 – DHCPv6 Client IPv6: Stateless Auto Configuration. The
Administrator Command Prompt window is displayed. The command prompt window includes
several tables. The header of the second table is Ethernet adapter Local Area Connection. In
this table, the Link-local IPv6 Address entry with the value of
fe80::584e:b99d:c18d:c130×11<Preferred> is highlighted. IPv6 hosts configure a link-local
address for each interface. A host can also determine the addresses of routers, additional
addresses, and other configuration parameters by using router discovery.]

Now, we're having a look here at this screen again, Jacob, but now, we're looking at it slightly
differently. We're seeing a different address, not just the link-local address. Instead, we see
also an assigned Iv6 address and here we're referring to a stateful autoconfiguration. So I have
a question here. Can you clear up for us, what is the difference between stateful and
stateless? That's an excellent question, one that people find confusing at times. The idea of a
stateless IPv6 address simply means no one else is keeping track of this address. It's never
written down in any database. When there is a link-local address, there is a predefined link-
local prefix that is already embedded in the operating system and you're simply coming up with
a unique suffix at the end of that for link-local address, so it's stateless, right. You came up with
it, you make sure no one else is using it right now, and then you go with it. Additionally, once
you've got that link-local address, your IPv6 stack is actually going to send out a multicast
asking is there a router that is willing to respond back to a...with a router advertisement
message that will identify for me what network I am on. What IPv6 subnet I'm on. Not this link-
local generic one, but my specific subnet that is defined, really, by this router and so the router
can tell me what subnet I belong to and then similar to the link-local, I can generate a unique
suffix to that IP prefix that's been given to me by the router and come up with an IP address
and the router could potentially even give me some other information. Well, that link-local has
that prefix of FE80, so what you're saying is, you know, that's the universal link-local prefix, but
now, we need to have a prefix that's specific to that network, that's what we're looking for now.
Exactly, for example, our, you know, 2001 db8 subnet, right. That's our network, that's where
we belong, that's what's my side of the router. And so everyone else on my side of the router
or in my VLAN has to have that same prefix or we can't talk, right. That's just the general rules
of IP. It applies for IPv6 as well. The thing here is the router actually can tell me what that is,
but unlike DHCP, the router doesn't keep track of the fact that it told me what its network prefix
is and it doesn't keep track of what suffix I might have come up with for my own unique host. It
is still stateless when a router tells you how to build an IP address, right, because there is no
state. There is no database maintaining this information. But there is another way that this
particular client could get an IP address, right. And that is the client could go through the
process of sending out a multicast to find a DHCP server, an IPv6 DHCP server, which could
then give me a stateful address, which means exactly the same thing it meant with IPv4, it
means that we have an IP address that's in a database, once we've gone through our
communication process back and forth and have agreed on an IPv6 address, again, in the
2001 db8 prefix, but now DHCP comes up with a unique suffix, assigns it to my MAC address,
and records that in the database. Now, we have a stateful address. Now, we have something
that would be, for example, coordinated in a failover server situation like we were talking about
before, that's the information that gets passed back and forth. So we go from stateless, link-
local, and even router defined addresses, stateless addresses like that to stateful addresses,
which really means I'll be able to see the active leases of an IP address in the DHCP
database.

[Heading: DHCP DHCPv6 – DHCPv6 Client IPv6: Stateful Auto Configuration. The
Administrator Command Prompt window is displayed. The command prompt window includes
several tables. The header of the second table is Ethernet adapter Local Area Connection. In
this table, the IPv6 Address entry with the value of
2001:db8::6b75:c37h:3554:6167<Preferred>, the Lease Obtained entry with the value of 21
January 2013 10:05:40, the DNS Servers entry with the value of 2001:db8::1000, and the
Connection-specific DNS Suffix Search List entry with the value of easynomadtravel.com are
highlighted. DHCPv6 is used to obtain addresses and other configuration options if there are
no IPv6 routers present or if a client receives router advertisement messages that do not
include address prefixes and require that the host use a stateful address configuration
protocol.]

3. DHCPv6 and IPv6

So now, we're looking at how the actual exchange work. This is, I think, something you were
speaking to earlier, Jacob, but what I noticed here is it doesn't actually use DORA. Discover,
offer, request, and acknowledgement. Yeah, we don't use those anymore. Instead, we're using
solicit, advertise, request, and reply. And gang, no one is going to be asking you to know these
four steps here if you're taking the exam, but it is important to understand just a little bit in the
background here that there is some different protocols that are a part of this process and as
we said, what's going to be a key difference? Remember, discovery is a broadcast and IPv6
does not play the broadcast game. Take a look if you would down at the bottom where we
have a little snippet of a packet analyzer capture and you'll see that our link-local address in
the first line is communicating with a specific, predefined multicast address. This is the
multicast address, ff02 with a host portion of 1:2. This is what is used by all DHCPv6 servers,
this is what they're listening in on to say, "Oh, you want an IPv6 address." Okay, let me see if I
can provide one for you, right. This is where they're tracking that is by listening in on this
multicast address. So that means that everything else that is not listening on this multicast
number gets to ignore all these solicitations. That's great. That means they don't have to
participate and you get better traffic out of your network because of it. It's one of the
improvements in working with v6. But otherwise, this four-step process is very similar. I, as a
client say, "I'd like to solicit an address." The DHCPv6 server says, "Oh, you want a stateful
address, let me see. Oh look, I've got one available that is associated with the subnet interface
that I just heard a solicitation on. Let me advertise to you a particular address." And notice this
is unicast going from the DHCP's unique IP, unique link-local address to the client's link-local
address. This is why we have link-local communication, right. This enables, no matter what, for
two local clients to unicast even though we haven't gone through DHCP yet. So they're going
to coordinate this advertisement unicast using the link-local addresses. The client receives the
advertisement, giddy with joy says, "Well, I'd like to request what you just offered me." Why
does it have to go back and request what was just advertised? Remember, there could be
more than one DHCPv6 server. Like v4, it will just respond to whichever server initiates that
communication first. Interestingly, you will notice this does actually go back out to the multicast
address meaning that other DHCPv6 servers that hear that I am requesting a different server's
advertisement can essentially take down their advertisement for me and make that IPv6
address available for a different client. That multicast address is ff02, right. ff02 indicates
multicasting, 1:2 is what indicates specifically this is a multicast for DHCP. So what you're
really saying is that DHCPv6 doesn't use DORA anymore. It doesn't use DORA, exactly. And
so, in the end, we just finish off with a reply and we've gone through SARR instead of DORA,
which is just…it doesn't have nearly the fun. It doesn't conjure up images of monkeys in
backpacks and, I don't know, DHCPv6 may not catch on because of that.

[Heading: DHCP DHCPv6 – DHCPv6 Messages. DHCPv6 does not use DORA. It uses SAAR.
The four steps in the SAAR process are: 1. client solicit 2. server advertise 3. client request,
and 4. service reply. A snippet of a packet analyzer capture is displayed. The first line in the
snippet reads fe80::c008:10ff:fee0:0 ff02::1:2 DHCPv6 112 Solicit XID: 0×126569 CID:
00030001c20810e00000. The second line reads fe80::c007:10ff:fee0:0 fe80::c008:10ff:fee
DHCPv6 176 Advertise XID: 0×126569 CID: 00030001c20810e00000. The third line reads
fe80::c008:10ff:fee0:0 ff02::1:2 DHCPv6 126 Request XID: 0×150f8e CID:
00030001c20810e00000. The fourth line reads fe80::c007:10ff:fee0:0 fe80::c008:10ff:fee
DHCPv6 176 Reply XID: 0×150f8e CID: 00030001c20810e00000.]

4. Demo: DHCPv6 configuration

When we take a look at IPv6 properties in a client, I want you to notice that we can Obtain an
IPv6 address automatically, but it doesn't indicate if it's stateful coming from a DHCP server
or a stateless coming off the router and going to advanced doesn't tell me anything more. So,
to manage that, we're going to head to netsh, the NetShell command allows me to
enumerate the addresses that are incorporated with this protocol – netsh int IPv6
show int and we can see three of them and I want to focus on Ethernet 2, which is index
number 5. And I add the 5 reference, it gives me the details on that and I want you to key on
just a couple of relevant items right here. And that is Router Discovery is enabled. I support
getting my IP address statelessly from the router.

[The General tabbed page of the Internet Protocol Version 6 (TCP/IPv6) Properties dialog box
is displayed. The tabbed page is divided into two sections. The first section has the Obtain an
IPv6 address automatically and Use the following IPv6 address radio buttons. Below the Use
the following IPv6 address radio button are the IPv6 address, Subnet prefix length, and Default
gateway text boxes. The second section has the Obtain DNS server address automatically and
Use the following DNS server addresses radio buttons. Below the Use the following DNS
server addresses radio button is the Preferred DNS server and the Alternate DNS server text
boxes. Next is the Validate settings upon exit checkbox and the Advanced button. The OK and
Cancel buttons are at the bottom of the dialog box. The instructor points to the Obtain an IPv6
address automatically checkbox. Then the instructor clicks the Advanced button to open a new
dialog box with two tabs – IP Settings and DNS. Then the instructor navigates to the command
prompt window. The first line in the command prompt window reads C:\Windows\system32>.
In this line, the instructor types netsh int ipv6 show int and presses the Enter key. The
command prompt window is populated with a table with five columns and three rows. The five
headers in the table are Idx, Met, MTU, State, and Name. In the first row, the entry under the
Idx header is 1, the entry under the Met header is 50, the entry under the MTU header is
4294967295, the entry under the State header is connected, and the entry under the Name
header is Loopback Pseudo-Interface 1. In the second row, the entry under the Idx header is 5,
the entry under the Met header is 5, the entry under the MTU header is 1500, the entry under
the State header is connected, and the entry under the Name header is Ethernet 2. In the third
row, the entry under the Idx header is 11, the entry under the Met header is 50, the entry under
the MTU header is 1280, the entry under the State header is disconnected, and the entry
under the Name header is isatap.corp.brocadero.com. The last line in the command prompt
window again reads C:\Windows\system32>. In this line, the instructor types netsh int ipv6
show int 5 and presses the Enter key. The command prompt window is populated with the
Interface Ethernet 2 Parameters table. The instructor highlights three rows in the Interface
Ethernet 2 Parameters table. The first row that the instructor highlights is the Router Discovery
entry with the value of enabled.]

Managed Address Configuration from a DHCP server is disabled by default as is Other

Stateful Configuration, which is what would allow me to receive my IP address from the router,
but get my other options like pixie servers, DNS servers, default gateway from my DHCP
service in a stateless way. How would I change this? Well, you guessed it, more netsh. Let's
take a look at these commands. I can execute the command netsh int IPv6 set int
5 routerdiscovery=disabled to say yeah, don't be listening to the routers, instead
netsh int IPv6 set int 5 managedaddress=enabled. Listen to your DHCPv6
server. So these options are going to give me exactly what I need. After doing this, I would
IPconfig, release, and renew in order to obtain an IP address from my DHCPv6 server.

[The command prompt window is displayed. In the Interface Ethernet 2 Parameters table, the
second row that the instructor highlights is the Managed Address Configuration entry with the
value of disabled. The third row that the instructor highlights is the Other Stateful Configuration
with the value of disabled. The last line of the command prompt window reads
C:\Windows\system32>. In this line, the instructor types cls and presses the Enter key to clear
the command prompt window of all entries. The first line in the command prompt window reads
C:\Windows\system32>. In this line, the instructor types netsh int ipv6 set int 5
routerdiscovery=disabled and presses the Enter key. The OK entry appears in the command
prompt window and the last line of the command prompt again reads C:\Windows\system 32>.
In this line, the instructor types netsh int ipv6 set int 5 managedaddress=enabled and presses
the Enter key. The command prompt window is populated with the OK entry. The last line in
the command prompt window again reads C:\Windows\system 32>.]
DHCP Service Management Strategic Design
Learning Objective
After completing this topic, you should be able to
◾ identify DHCP management options in Windows Server 2012

1. DHCP interoperability
The thing about DHCP is that, you know, in and of itself, it's probably not that hard to
configure, just know the boundaries of your IP addresses, the options for what to point people
to in terms of other resources. You're doing a good job, but DHCP doesn't exist in a vacuum.
What are some of the other services that we end up having to coordinate with and get
configured correctly or we're going to have headaches. Well, let's start with Active Directory.
When you introduce a DHCP server in your organization and you have Active Directory
available and it's a Windows-based DHCP server, what it does is it checks in to see if it has
permission to be distributing addresses and the reason for this is to prevent rogue DHCP
servers from being dropped in, you know, in your environment and misdirecting clients either
intentionally or unintentionally. Windows DHCP is where this validation takes place, so Active
Directory authorization is important as kind of a check and balance there to further protect your
network. Now, in addition to that, Active Directory relies on DNS as kind of its primary way of
locating each other. DCs locating other DCs, but clients locating resources, and clients locating
other clients, and so forth. So DHCP can also integrate with Active Directory and DNS in the
sense that it can register a client's records into the DNS database if you have dynamic DNS
enabled. Now, some organizations don't use dynamic DNS, some do. What's nice about
dynamic DNS is it automatically populates, you know, the DNS database for easy lookups.
And so, if you need to, DHCP can take that burden off of the clients and you have a more
managed and controlled, more secure way of actually registering those records into DNS
because it's coming strictly from your DHCP servers. Now, DHCP can also work in terms of
security with NAP. In other words, NAP, which is the Network Access Protection feature, is
kind of a health check when wireless clients or new clients come into your network. What you
can do is you can set up a DHCP configuration with DHCP or I should put it this way, you can
configure a NAP configuration with DHCP enforcement and what that simply means is when a
client comes on, they're not going to get a DHCP address unless they meet the health codes, if
you will, the health codes of the network. They have the firewall turned on. They have the
latest virus definitions and such. Now, if they don't actually meet the health code of the
network, well, DHCP can give them a remedial address, if you will, an address for a
remediation network where they can go get patched up, quarantined for a little bit until they're
healthy again, and then they can access the other parts of the network. And the last one here
that's mentioned is IPAM, the IP Address Management feature that comes in Windows Server
2012, which is a comprehensive IP management suite, which allows you to basically view,
manage, and monitor all of your IP services including DHCP, but also DNS, and IP addresses
themselves and so it integrates well, of course, with IPAM as a way for administrators to kind
of get a handle in all of that IP configuration out there.

[DHCP Interoperability. DHCP supports secure authorization within an Active Directory forest.
DHCP supports secure dynamic record updates to the DNS zones. NAP can utilize the DHCP
service as a client network access management mechanism, and IPAM and System Center
2012 Operations Manager DHCP Management Pack enable advanced logging and monitoring
of a DHCP serviced environment.]

So here is a closer look at how DHCP and DNS actually interoperate. Jacob, explain this
transaction for us. You'd like me to do that, wouldn't you? Gang, it's just this simple. Your client
gets an IP address from DHCP, right. That whole process occurs, whether it's a DORA or
SARR, we get our IP address in place. Then DHCP can go through the process of dynamically
updating that client's name and that client's stateful IP address to the DNS server thereby
enabling that process to be relieved from being a client responsibility. That means that your
client boot times and processes are going to be sped up because this is one operation they
don't have to take care of and often what ends up happening. Our DHCP server, our DNS
server, they may be on the same server or they may, at least, be within the same server
subnet and so we're enforcing that the traffic can stay more localized. But what we're seeing
here is that there is a lot of ways that this could break, a lot of places we could turn this off, and
if we disable this feature, we're not supporting it in many of these locales, then we're going to
have an issue. So on the client, first thing, in our TCP/IP properties, if you head to the DNS tab
and you work your way down to the bottom, you could deselect the option to support
dynamically registering your records, so you're saying as a client, I'm wanting to fly under the
radar and not have my name and IP address and that centralized phonebook of DNS. Okay,
that's true, you could do that and if so, you won't be registered by default. If you take a look at
the DHCP server in both the scope and at the server level, depending on the level of
management that we want to enforce here, we can describe the DNS integration properties
and so we can support dynamic updates or we could uncheck that there, so maybe the client is
willing to do it, but the DHCP server says, no, I'm not doing dynamic registration, you're on
your own, client, and if that's the case, if the DHCP server is not set to perform the dynamic
updates, but the client is, well then, the client simply does their own update. It's not like it
breaks the dynamic update from occurring, it simply means the server won't be doing it. We
also have the option to enforce that we want to support always dynamically updating even
clients that have disabled that setting in their advanced TCP/IP properties for DNS, the option
to do dynamic update themselves, so the client is wanting to fly under the radar, but the DHCP
service says, no, everybody gets posted and remember, this is posting both the (a) the
address record and the reverse lookup record, the IP, the name record assuming that, that
zone is found in the DNS server. You also have the ability to define support for Legacy clients
or UNIX clients that don't support this protocol. Though it's worth a flag, essentially, in the
packet to say, please, do register me or don't register me. Then, finally, the last place where
this could break or we have an option to configure is on the DNS server, right. The DNS server
that's receiving this. It's very normal for DNS servers to support dynamic update within the
LAN, within the network infrastructure that we manage behind our firewall, our Active Directory
side network. We can configure that to support secure updates or unsecure updates, both of
which can work in conjunction with DHCP as long as that DHCP server is a part of the domain
or a trusted domain if we're talking about a secure-only dynamic update, because remember
secure only means there is actually going to be Kerberos authentication that's behind the
scenes in this process ensuring the validation of this update is not coming from someone who
is posing as an authoritative server to do a dynamic update for a particular name, but is
validated by the fact that their name and password has gone against the domain controller
and, therefore, can coordinate this process. In this case, the name and password is going to
be associated by default with the computer account of the DHCP server. That is, we're going to
see when it comes to secure dynamic updates, we have some important options that we can
choose to manage this and to make it more flexible to supporting multiple DHCP servers all
registering to a set of DNS servers.

[Heading: DHCP Interoperability – DNS Record Update Process. The four steps in the DNS
record update process are as follows: 1. the DHCP client with a HostName sends the IP lease
request to the DHCP server 2. the DHCP server sends the IP lease acknowledgement back to
the DHCP client 3. the DHCP server performs DNS dynamic update of the host (A) name with
the DNS server, and 4. the DHCP server performs DNS dynamic update of the pointer name
(PTR) with the DNS server The DNS tabbed page of the DHCP client's Advanced TCP/IP
Settings dialog box is displayed. In the DNS tabbed page, the Register this connection's
addresses in DNS and the Use this connection's DNS suffix in DNS registration checkboxes
are highlighted. Then the DNS tabbed page of the DHCP server's Scope [192.168.1.0]
ENTscope01 Properties dialog box is displayed. Then the General tabbed page of the DNS
server's easynomadtravel.com Properties dialog box is displayed. In the General tabbed page,
the Dynamic updates drop-down list box with the default entry of Secure only is highlighted.]

2. DHCP dynamic updates

So this is actually where you can go in and configure the Credentials because, Jacob, you
were saying Kerberos is behind that dynamic update exchange. Here it shows us how we can
actually put in Credentials to support that authentication as part of that dynamic update. That's
right and so what we're looking at here, you can see that there is a list here of specific User
name from a specific Domain with a specific Password. Somebody created that user account
and defined that password and then took that account and placed it within the DNS update
proxy group that is stored in Active Directory. We see a reference to that group over there on
the right-hand side by the domain controller and so the idea is, I could have five servers that
share one common update account that they use to perform the dynamic update into DNS. If
you didn't do that, if you just used the default configuration without specifying credentials, then
that DNS update proxy group would actually need to hold the computer accounts of those five
DHCP servers that we have in our network that are doing the updates of our DNS server. Let's
talk about why that's necessary for a minute and what kind of problems you might have in a
certain circumstance. Imagine a client gets an IP address from DHCP server A, network's out,
great, they've got a client, IP address, DHCP server is set to do secure dynamic update, they
contact the DNS server, they are able to add the record because they have the authority, they
are a trusted member of the domain, so they add the record, okay. Now later, the client, within
the same AD infrastructure ends up moving to another location, maybe failing over to another
server, maybe it's a split-scope situation, so many reasons why a client might get an IP
address from a different DHCP server in my network. When that same client, now with a new
IP address, contacts DHCP, they get a valid IP address, that part is taken care of. The client
says, "please register me." The DHCP server says, "I love to register clients." They contact the
DNS server. They attempt to update the record, but now there is a record in Active Directory
that is owned by the first DHCP server. This goes back to the fact that DNS can be embedded
in Active Directory and when we're talking about secure dynamic updates, they have to be
embedded in Active Directory and part of what's maintained because it's embedded in Active
Directory is permissions to this resource record. This one line item that says client A is at this
IP address. DHCP server B doesn't have permissions to update that record because it was
added by DHCP server A, only A has the ability to go in and update that record. You see the
problem. But, if all of these servers were either...were using this common set of update
credentials, which is a member of the DNS update proxy group, then when a member of that
group performs that registration, it enables the account to be updated by any member of that
group, anyone using these common update credentials, so this is a much simpler way to
manage this and make it flexible, right. As we roll out a new DHCP server in our IPv4
properties, IPv6 properties are in the scope properties, we specify the update credentials, we
reference the account that we made a member of the DNS update proxy, and it just works. All
the dynamic updates occur whether I get an IP address from server A and then failover to
server B or vice versa. I always am able to have my current up-to-date IP address reflected in
DNS without there being any issues. So this address that concern around dynamic updates,
the risk of kind of a machine coming in and trying to alter and hijack DNS records. We turn on
secure dynamic update and we restrict it to just the DHCP servers, we're going to have a more
secure DNS registration.

[Heading: DHCP Interoperability – DNS Update Account. The Advanced tabbed page of the
IPv4 Properties dialog box is displayed. The Advanced tabbed page has the Conflict detection
attempts spin box with the entry of 0 and the Audit log file path text box with the entry of
C:\Windows\system32\dhcp. Below the text box is the standard text "Change server
connection bindings." Next to the standard text "Change server connection bindings" is the
Bindings button. Below the standard text "Change server connection bindings" is the standard
text "DNS dynamic update registration credentials." Next to the standard text "DNS dynamic
update registration credentials" is the Credentials button. The DNS dynamic update credentials
dialog box is also displayed. The DNS dynamic update credentials dialog box appears by
clicking the Credentials button in the Advanced tabbed page of the IPv4 Properties dialog box.
The DNS dynamic update credentials dialog box has the User name, Domain, Password, and
Confirm Password text boxes. Then the General tabbed page of the DnsUpdateProxy
Properties dialog box is displayed. The General tabbed page has the Group name (pre-
Windows 2000), Description, and E-mail text boxes. Below the E-mail text box are two sections
titled Group scope and Group type. The Group scope section has three radio buttons –
Domain local, Global, and Universal. The Group type section has two radio buttons – Security
and Distribution. Below the two sections is the Notes text box. The OK, Cancel, Apply, and
Help buttons are at the bottom of the dialog box.]

3. AD DS authorization of the DHCP service

Well, Jason, one of the things that an administrator who is going to manage DHCP learns very
quickly if they are implementing a brand new DHCP server is that you can't get anything off the
ground until you get that DHCP server authorized in Active Directory. What are some of the
design principles that we need to think about with regard to authorization, some best practices,
some concerns that might come up with regard to this process? Well, this is what I was
speaking about earlier in regards to protecting your network from rogue DHCP servers. Now,
the idea here is the DHCP server who is passing out addresses in an unauthorized manner
and I've actually done this. I've made this mistake bringing in a test server and adding an
uplink to the network and passing out addresses to machines that were good for the lab but
not accurate for everybody else. This is back before the days of virtualization where I could
contain my lab's internal, but anyway. So we have this concern about this in terms of denial of
service, so we can restrict and protect our network from Windows DHCP servers because they
always do this check in, right. They come up, hey, there is Active Directory, let me check and
see if I can actually do my thing. Now, to authorize a legitimate DHCP server though, you have
to have credentials in Active Directory. So, Jacob, the primary design concern that comes to
my mind is who gets to do this? Only members of that enterprise admins group is permitted to
actually authorize DHCP servers and that sounds like a lot of credentials for a small task, but
passing out those addresses in an unauthorized fashion could be pretty destructive to the
entire network, even temporarily, so you might have to consider who is actually going to be
responsible for authorizing incoming DHCP servers.

[Heading: DHCP Interoperability – DHCP Service Authorization in Active Directory. In Server

2012, at startup, any member DHCP services will query Active Directory for the list of
authorized servers (identified by IP address). If a DHCP service's host server is not in the list of
authorized DHCP servers, the server hosting the DHCP service will not respond to clients. The
DHCP window is displayed. Running along the top of the window are the File, Action, View,
and Help menus. Below the menu bar is the tool bar with various buttons such as the Back and
Forward buttons. Below the tool bar, the window is divided into two areas. The area to the left
consists of a directory structure with nodes and subnodes. The area to the right shows
information about the nodes and subnodes selected in the area to the left. The main node in
the area to the left is the DHCP node. In the example, the shortcut menu of the DHCP node is
displayed. The shortcut menu has three options – Add Server, Manage Authorized servers,
and Help. Then the Manage Authorized Servers dialog box that appears when selecting the
Manage authorized servers shortcut menu option is displayed. The Manage Authorized
Servers dialog box has the Authorized DHCP servers section. The section consists of a table
with only two of the headers visible. The first header is Name and the second header is IP
Address. There are two rows under the headers. In the first row, the entry under the Name
header is server2012-01.easynomadtravel.com and the entry under the IP Address header is
192.168.1.10. In the second row, the entry under the Name header is server 2012-
10.easynomadtravel.com and the entry under the IP Address header is 192.168.1.20. Next to
the section are the Authorize, Unauthorize, and Refresh buttons. The standard text below the
section reads "To add a computer to the DHCP console, select the computer, and then click
OK."]

4. DHCP and NAP integration

So DHCP authorization is one measure for protecting our network. What are some other
technologies that DHCP can do that contributes to security? Well, if you think about the NAP
integration option for DHCP, it definitely is a piece of our security. That ability to say, all right,
let me take this incoming request for an IP address, take the credentials associated with the
system, that client system, and information about that system, have that information be
gathered, forwarded on, and processed by an NPS health policy server determine, okay, this
guy is patched, he has got his firewall enabled, he is looking good to go. Okay, DHCP server,
let him have an IP address in our normal compliant based subnet, right, right along with all of
his other friends. But, if a client shows up, right, and you know this client, right, it's a laptop, it's
been out in the wild for three months, Windows update's been turned off, it's your worst
nightmare. But suddenly, there it is, plopped into your network and you don't want this disease
ridden, infected piece of disgusting computer malware to disrupt all your network
communications, right. To bring you down to your knees just because you're trying to support
this, so that's where you say, wait, wait, wait, let's double check. You've got your antimalware
installed, you got your antivirus installed, your firewall is up to date, your patches are good. Oh,
no, you haven't done patches for three months? Okay, let me give you an IP address. This IP
address is going to be an IP address in a noncompliant subnet. In other words, I'm putting you
in time-out for a little bit, right. And then I will, in that noncompliant subnet, through the NPS
policy server, provide access to a remediation server. That remediation server is probably
going to have WSUS on it and be available for your ability to connect and find that support, or
that noncompliant subnet will have access through a very controlled router to have Internet
access for the purpose of Microsoft updates, if that's how you want it, but, you see, it's very,
very tightly organized to ensure that you can get fixed first and foremost. Go through that
remediation process and then once your acts are all cleaned up, you can be brought back into
the compliant subnet, right. Once you've proven your compliance, then you can be given a new
IP address from DHCP that's a part of the regular compliant subnet. Now, notice you haven't
physically changed where your location is, we haven't put you on a separate VLAN, we've just
given you an IP address, which only matches the subnet ID with a remediation server or other
specific destinations that we want to allow that have these IP addresses bound to them that
allow for access. So that means that this is a security option, right. We can enable this. We can
support the ability to integrate in with network access protection, but, a big but behind this. If
you were to statically configure your IP address, would you get around this whole thing? Yeah.
There wouldn't be anything going on here in any communication, any protection. So this is the
weakest form of network policy server health policies that you can configure is the DHCP one.
IPSec is vastly more secure, 8021x and the switches and wireless vastly more secure,
because this is a layer 3 component coming in here. I've already got a plugin to the network,
right. I could already start doing network sniffing and all of that even without an IP address. So
be aware that, and this is especially important from a design perspective and if you're taking
the exam, that compared to other NPS solutions, this is the least preferred, but it is built in, it's
easy to utilize, easy to call upon, and find your trusted clients, and let them in or not.

[Heading: DHCP Interoperability – DHCP and NAP Integration. The example shows a secure
subnet, a compliant subnet, a non-compliant subnet, and a DHCP server. The secure subnet
contains the NPS health policy server, the compliant subnet contains three clients, and the
noncompliant subnet contains the remediation server. The DHCP server is placed between the
three subnets. The Network Access Protection tabbed pages of the IPv4 Properties and the
Scope [192.168.1.0] Ent-Scope01 Properties dialog boxes are displayed. The Network Access
Protection tabbed page of the IPv4 Properties dialog box has the Network Access Protection
Settings section consisting of two buttons – Enable on all scopes and Disable on all scopes.
The Network Access Protection tabbed page of the Scope [192.168.1.0] Ent-Scope01
Properties dialog box has the Network Access Protection Settings section, which includes the
Enable for this scope and the Disable for this scope radio buttons.]

5. DHCP filtering
One of the challenges that we sometimes face with DHCP is ensuring that we are trusting
certain clients to be able to connect and get an IP address and ensuring that there may be
certain addresses that we do not allow this DHCP server to be able to coordinate with and so
we have the ability to manage MAC address filters. And you can think of this almost like with a
wireless device, the ability to configure MAC address filters and say, okay, I only want to trust
these particular clients. That would be very small-scale environment to have a discrete, allow
filter, and assume everything else is denied. The other option, of course, would be a deny filter.
Oh, we had this contractor coming with their laptop, I've got their MAC address, I gave them an
IP address, but I am going to add that particular MAC address to my deny list so that they don't
get a chance to come back in at any later date and get an IP address, instead I've got them
blocked at that point, especially if there was anything, you know, malicious that went on.
Couple of key things to remember about this is that you'll need to Enable these filters. We can
populate them, but separately, we have to actually Enable them and then we'll, again, all
you're putting in there is MAC addresses I allow, MAC addresses I deny. It's a very simple
operation, but right there on the front end of DHCP, very powerful to configure and if you have
multiple DHCP servers, these are exportable and importable so that you're consistent over the
long haul between servers, which you can automate with scheduled jobs if necessary.

[Heading: DHCP Filtering – Using the DHCP Console to Activate the MAC Filters Lists. The
DHCP window is displayed. Running along the top of the window are the File, Action, View,
and Help menus. Below the menu bar is the tool bar, which contains various buttons such as
the Back and Forward buttons. Below the tool bar, the window is divided into two areas. The
area to the left consists of a directory structure with nodes and subnodes. The area to the right
shows information about the node or subnode that is selected in the area to the left. In the area
to the left, the shortcut menu for the Allow subnode is displayed. The shortcut menu consists of
six options – New Filter, Enable, View, Refresh, Export list, and Help. The Enable shortcut
menu option is highlighted.]

So the MAC address helps us determine allows and denies, but what if you have different
types of allows? What I mean, Jacob, is a network consist of all kinds of devices, right? You
have phones, you have desktops, and you have guest machines coming in the network, and
then laptops, since you have different classes of devices, if you will. And sometimes you might
have on your routers, a need to establish different quality of service policies for your phones
versus your desktops. One way to do that is to assign them different IP addresses from
different subnets. Another thing you might need to distinguish between these different devices
is maybe different parameters, different options, maybe they need different gateways, different
lease durations, that sort of thing. Do I have any controls in DHCP that enables me to target
machines and assign them different configuration settings? We certainly do and the options
that we have in 2012 are more available, more pervasive, more discriminating than we've had
in previous versions of DHCP. What I mean is this. In previous versions of DHCP, we could do
things like recognize, oh, you're a Microsoft client? Let me give you a couple of Microsoft
options through the use of a special advanced vendor class option and to define those, you
just go into options and you would essentially say, "I have a specific property that only applies
if you have this particular vendor coming in." You also have user classes that we could call
upon and again, you'd have an advanced option to be able to define a user class, say, laptops
or phones or something like that, so you could define a class ID, you'd have to go to the client
and then specify that particular class ID locally there, but, if you've done that then, okay, you
could get a different lease time or you could get a special DNS server, right, or coordinate
differently, maybe work with pixie. So we have the ability to define these special options for
certain cases, but now, we have what's called a policy, okay. This idea of defining policies in
DHCP is very cool. Policy based assignment of options and IP addresses allows you to, again,
differentiate between laptops, desktops, servers, phones, printers, standard desktops, virtual
environments and we can filter based upon things like your vendor class and your user class
still and, in fact, if you open up DHCP in 2012 and you went looking for user class options,
you're like where did they go? They're buried in policies. You have the ability also to filter
based upon MAC address prefixes. Maybe you know your IP phones use a certain MAC
address prefix. We can wildcard those and reference those. Other client identifiers, which relay
agents you came from, so we have the ability to track these and we can do more with them.
Based upon a policy, we can assign some different options, but unlike previous versions, we
actually could differentiate which scope to assign an IP address from. We didn't have that
ability before. We could change options, but not which IP address range you might receive an
IP from. We can define standard options and we can define those vendor-specific options like
IP phone options or Microsoft proprietary options that DHCP has the ability to fulfill. So this is
about that finessed, tailored, targeted ability to assign options in IP addresses to two clients
that, in terms of their DORA message, look the same initially, but I take in some of the
attributes of those particular clients and then I'm going to give them back IP addresses and
options that make sense for that particular client. It's a very cool feature.

[Heading: DHCP Filtering – Creating MAC Filters in DHCP Scope-Based Policies. The DHCP
window is displayed. Running along the top of the window are the File, Action, View, and Help
menus. Below the menu bar is the tool bar with various buttons such as the Back and Forward
buttons. Below the tool bar, the window is divided into two areas. The area to the left consists
of a directory structure with nodes and subnodes. The area to the right shows information
about the node or subnode that is selected in the area to the left. In the area to the left, the
shortcut menu for the Policies subnode is displayed. The shortcut menu has six options – New
Policy, Deactivate, View, Refresh, Export List, and Help. The New Policy shortcut menu is
highlighted. The DHCP Policy Configuration Wizard is then displayed. The wizard appears
when the New Policy shortcut menu option is selected.]
DHCP Database Management
Learning Objective
After completing this topic, you should be able to
◾ match the tasks to administer the DHCP database and scopes to their correct
descriptions

1. DHCP database maintenance

Well, we've been focusing a lot on what to do with the DHCP server, different configuration
options that you can make, but as an administrator who is designing this, I need to be thinking
about am I ensuring the recoverability of my DHCP environment? We ensured, hopefully,
availability when we talked about split-scopes and our ability to use failover or clusters, but
here we're talking about recovery. I mean, what if I need to go back to a previous version?
What if the database gets corrupted? So I need to be ensuring that I'm backing up my content
and content means the content of that database, which holds my scopes, the actual client
leases, the super-scopes, right, when I've got multiple IP subnets that share a common LAN
when I've got multicast scopes for those Madcap applications like Windows deployment
services that needs a unique multicast address to hand out to its clients, but it doesn't really
matter what it is. When we need to get all the little options in place and, remember, we also
need to be ensuring that we are backing up the content of the registry, right. And so that's an
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters. It's
maintaining some properties regarding DHCP here as well. So I want to ensure that I'm
backing up DHCP. And that process, out of the box with me doing nothing, happens every
hour automatically to a subfolder of the DHCP directory. So, Jason, you know, I can go into the
properties and I can change where the database is located, the backup path is located, I could
go into the registry and change the interval. Are there any good reasons for stepping away
from the defaults or do we generally leave things the way they are? Well, I've never gone in
and found a need to change the interval as far as how frequently it does the backups, but, you
know, it might be a good idea to change the database, perhaps. The best practice is to have
that database location on a separate volume from where you've installed DHCP, so you can go
in and alter that and if you needed to change that interval, you could certainly do that and I
think that would depend on in terms of the changes and the size of that database would have a
factor. And one of the things that I've got done in here that could be useful is perform manual
backups, so you can do the synchronous backups where DHCP automatically does it for you,
but, if you're going to actually add a new service pack or do some sort of change. Well, before
you make that change, you can still go in and do a manual backup and that's useful as well.

[Heading: DHCP Database – Active and Backup Location Modification. The content in a DHCP
database that has to backed up consists of the following: All scopes – Standard, super-scopes,
and multicast scopes. Reservations and leases. All DHCP options – Server options, scope
options, reservation options, and class options. DHCP policies – Server-level policies and
scope-level policies. All registry keys and other configuration settings – These settings are
stored in the following registry sub key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services|DHCPServer\Parameters.
The DHCP window is displayed. In the area to the left, the shortcut menu for the server2012-
01.easynomadtravel.com node is displayed. The shortcut menu consists of several options.
The Properties shortcut menu option is highlighted. The Advanced tabbed page of the
server2012-01.easynomadtravel.com Properties dialog box is also displayed. The server2012-
01.easynomadtravel.com Properties dialog box appears when the Properties shortcut menu
option is selected. The Advanced tabbed page has the Database path and the Backup path
text boxes. Next to each text box is the Browse button.]

Now, other reasons why you might come in and look at your database here has to do with
inconsistencies. Jacob, do we have anything here regarding addressing, you know,
troubleshooting inconsistencies in my database. Well, that's one of the things that can happen
because of what we just said, right. There is a summary set of information about your leases
maintaining the registry when we reference that path. If you take a look on the reconciliation
tab, you can see that we can go into our server and say that we want to reconcile our scopes.
And what we're talking about is typically after restoring backup, for example, we may find that
there is database information regarding active leases that is different than the information
about those leases that is recorded in the registry and so one of the great things about the way
that backup and restore works is I can restore the database, which, again, here is our definition
for our scopes, here is our definitions of our policies and everything else, but my leases might
be an hour old if I'm using the most recent backup, right. But those leases are still referenced
in the registry and so, when there's active leases that are in the registry, but are not in the
current database, the reconciliation tool can essentially allow those to be populated for me. It
allows me to kind of resurrect those from the grave to say, okay, you're out of sync here when
it comes to leases, to bring those back into consideration instead of getting error messages or,
maybe, accidentally handing out duplicate IP addresses. This reconciliation tool helps to bring
things to a point of balance the way that they should be. It's a great feature to use, again
typically, after a backup restore process.

[Heading: DHCP Database – Reconcile all IPv4 Scopes to the DHCP Database. DHCP
reconciliation is a tool to sync the database to the summary registry DHCP information, for
example, when an administrator has restored a DHCP database, but the restored DHCP
database does not have the most recent values. The DHCP window is displayed. In the area to
the left, the shortcut menu for the IPv4 subnode is displayed. In the shortcut menu, the
Reconcile All Scopes shortcut menu option is highlighted. Then the Reconcile All Scopes
dialog box and the DHCP pop-up box appear. The Reconcile All Scopes dialog box appears
when the Reconcile All Scopes shortcut menu is selected. The Reconcile All Scopes dialog
box has a blank table with two headers – Scope and IP Address. The Verify and Cancel
buttons are at the bottom of the dialog box. The DHCP pop-up box appears when the Verify
button is clicked. The text in the DHCP pop-up box reads, "The database is consistent."]

2. DHCP database migration and failover

All right, Jason, so we've been discussing backup and restore and reconciliation, but then
there is that other need to take our existing environment, maybe, that we've got in 2008 or in
another 2012 server, and to bring over that content, migrate it to another 2012 server. Let's talk
about what kind of options we have for making that happen. Well, basically, there's two ways in
which you can migrate DHCP. You can use the migration tools or you can use, you know, a
database import and export. So here we've got the PowerShell syntax showing us how to do
that. In the earlier systems, we just used NetShell.
[Heading: DHCP Service Migration – Concept. In the example, a Server 2012 with Windows 8
PowerShell is remoted to the retiring DHCP server – a Server 2008, 2008 R2, or 2012 DHCP
service-hosting server and the DHCP service settings are exported to the new DHCP server
using PowerShell syntax. The PowerShell syntax reads as follows: PS> Import-DhcpServer -
ComputerName DHCP01.easynomadtravel.com -Leases -File C:\export\dhcpexp.xml -
BackupPath C:\dhcp\backup\ -Verbose Next an exam tip is displayed. The text in the exam tip
reads, "Know how to use PowerShell to migrate or move DHCP data!"]
Planning a DHCP Solution
Learning Objective
After completing this topic, you should be able to
◾ plan a DHCP Solution

1. Planning the DHCP design

Now that you've seen how to design and maintain a Dynamic Host Configuration Protocol
(DHCP) solution in Windows Server 2012 R2, let's try an exercise.

You are planning a DHCP deployment within your Windows Server 2012 network infrastructure
to enable centralized

automatic management of IP addresses and other TCP/IP option settings for network clients.

Question

For the initial planning of your DHCP deployment solution, you decide to review the
stages of the DHCP design process.

Match each DHCP design process task to the correct design stage.

Options:

A. Determine the DHCP service address allocation method

B. Create the DHCP design configuration including any reservations
C. Map the design configuration to the existing hardware and software

Targets:

1. Design stage 1
2. Design stage 2
3. Design stage 3

Answer

Design stage 1 of the DHCP design process involves determining the DHCP service
method, which includes three address allocation methods: manual, allocated using
BOOTP, and automated DHCP allocation.

Design stage 2 of the DHCP design process involves creating a DHCP design
configuration, including items such as the design options for static IP addressing,
 dynamic addressing and DHCP scopes, availability and fault tolerance, routing
requirements, policies, and network access security.

Design stage 3 of the DHCP design process involves mapping the design
configuration to the existing hardware and software or mapping it to new hardware
and software specification, configuration, and capacity.

Correct answer(s):

Target 1 = Option A

Target 2 = Option B

Target 3 = Option C

Question

You need to ensure a high-availability DHCP design will have a centralized backup in
which a secondary DHCP service will act as a failover to primary local DHCP
services at the branch sites. It must be configured so that there is a continuous client
address lease renewal capability, deployed on a per service basis and by individual
scope, as well as be cost effective and simple to implement.

What high-availability DHCP design will meet your requirements?

Options:

1. Split-scopes
2. Failover cluster
3. DHCP failover in hot standby mode
4. DHCP failover in load sharing mode

Answer

Option 1: Incorrect. Split-scope DHCP uses two independent DHCP servers that
share responsibility for a scope. The DHCP is split into two parts with a portion of the
scope pool assigned to the primary DHCP server service, while the remaining portion
is allocated to a backup DHCP service. When network devices cannot reach the
primary server, they can request IP configuration from the backup service causing a
small delay.

Option 2: Incorrect. Failover cluster deploys the DHCP service as service application
in an active/passive failover cluster arrangement. In this arrangement, a passive
 failover server kicks in as the failover when the primary DHCP service-hosting server
fails. This method is expensive and more complex than other methods and does not
meet requirements.

Option 3: Correct. The DHCP service failover feature in hot standby mode is best
where the secondary backup DHCP service acts as failover to primary local DHCP
services at remote offices and sites. This method uses two DHCP services hosted on
two separate servers running Server 2012 that provide DHCP configuration settings
to the same scope and devices. All information is exchanged and replicated.

Option 4: Incorrect. Although DHCP failover in load sharing mode can provide the
same high available options required, the load sharing mode of operation is best
suited to deployments where both servers in a failover relationship are located at the
same physical site and not multiple sites.

Correct answer(s):

3. DHCP failover in hot standby mode

Question

You need to use IPv6 throughout the environment and are looking at the various
ways in which client IPv6 addresses and DHCP options can be configured.

You want the ability for the clients to self-assign a link-local address with the fe80
IPv6 address prefix.

Options:

1. Stateless Interface Address Autoconfiguration

2. Manual Interface Address Configuration
3. Stateful Interface Address Autoconfiguration

Answer

Option 1: Correct. On a Server 2012-controlled network where no IPv6 scopes have

been defined on the DHCP service, and therefore no scope prefixes, the Windows
client will simply self-assign a link-local address with the fe80 IPv6 address prefix
without recourse to a DHCP service when using Stateless Interface Address
Autoconfiguration.

Option 2: Incorrect. With manual interface address configuration, the IPv6 address is
configured at the client by manually assigning an IP address and other DHCP
 settings including DNS server and DNS
dynamic update.

Option 3: Incorrect. Stateful Interface Address Autoconfiguration allows addressing

to be performed directly by the Server 2012 DHCP service itself.

Correct answer(s):

1. Stateless Interface Address Autoconfiguration

Question

You need to configure the DHCPv6 server with a static IP address on its connecting
interface.

The IPv6 subnet is 2001:0db8:0:0/64 and the host address is 0:0:0:1000.

Code
INSERT THE MISSING CODE

Answer

To configure the DHCPv6 server with a static IP address on the target interface when
the IPv6 subnet is 2001:0db8:0:0/64 and the host address is 0:0:0:1000, you type
2001:db8::1000 into the IPv6 address field.

Correct answer(s):

1. 2001:db8::1000

Question

You are designing DHCP and DNS interoperability and have no choice but to host
both the DHCP service and domain controllers on the same computer.

Then you need to configure the DHCP service to use a dedicated user account.

Options:
 1. Credentials
2. DNS
3. General

Answer

Option 1: The Credentials option will allow you to type the credentials in for a
precreated user account that the DHCP server will supply when registering names
using DNS secure dynamic updates.

Option 2: The DNS tab is to configure DNS settings such as interoperability and
name protection options. You cannot configure the dynamic update user account
credentials.

Option 3: The General tab is for configuring IP address, gateway, and DNS server
parameters. You cannot use this area to configure the dynamic update user account
credentials.

Correct answer(s):

1. Credentials

Question

You need to migrate the DHCP server role from Windows 2008 to Windows Server
2012 R2. You have logged into the windows 2008 Server, started PowerShell with
elevated rights, created the TEMP folder and now you want to export the DHCP
server configuration, all scope data, and lease data to an XML file for DHCP server
dhcp.easynomadtravel.com."

Complete the code to export all the DHCP server information including scopes
present on the "dhcp.easynomadtravel.com" server to "exports\dhcpexp.xml" file
using the Export-DhcpServer dhcp.easynomadtravel.com cmdlet.

Code
PS > Export-DhcpServer –ComputerName dhcp.easynomadtravel.com

Answer

Correct answer(s):

1. -Leases -File C:\exports\dhcpexp.xml

2. -leases –file c:\exports\dhcpexp.xml
© 2018 Skillsoft Ireland Limited