Multicasting occurs when one machine communicates to a network of subscribed computers rather than specifically addressing each computer on the destination network. It’s much more efficient to multicast a video or audio stream to multiple destinations than it is to unicast it to the same number of clients, and the increased demand for multicast-f riendly network hardware has resulted in some head scratching about how to automate the multicast configuration.
In the following sections, you will learn about MADCAP, the protocol that controls multicasting, and about how to build and configure a multicast scope.
Understanding the Multicast Address Dynamic Client
Allocation Protocol
DHCP is usually used to assign IP configuration information for unicast (or one- to- one) network communications. With multicast, there’s a separate type of address space assigned from 224.0.0.0 through 239.255.255.255. Addresses in this space are known as Class D addresses, or simply multicast addresses. Clients can participate in a multicast just by knowing (and using) the multicast address for the content they want to receive. However, multicast clients also need to have an ordinary IP address.
How do clients know what address to use? Ordinary DHCP won’t help because it’s designed to assign IP addresses and option information to one client at a time. Realizing this, the Internet Engineering Task Force (IETF) defined a new protocol: Multicast Address Dynamic Client Allocation Protocol (MADCAP). MADCAP provides an analog to DHCP but for multicast use. A MADCAP server issues leases for multicast addresses only.
MADCAP clients can request a multicast lease when they want to participate in a multicast.
DHCP and MADCAP have some important differences. First you have to realize that the two are totally separate. A single server can be a DHCP server, a MADCAP server, or both; no implied or actual relation exists between the two. Likewise, clients can use DHCP and/or MADCAP at the same time— the only requirement is that every MADCAP client has to get a unicast IP address from somewhere.
Remember that DHCP can assign options as part of the lease process but MADCAP cannot. The only thing MADCAP does is dynamically assign multicast addresses.
Building Multicast Scopes
Most of the steps you go through when creating a multicast scope are identical to those required for an ordinary unicast scope. Exercise 6.7 highlights the differences.
EXERCISE 6.7
Creating a New Multicast Scope
- Open the DHCP snap- in by selecting Administrative Tools ➢ DHCP.
- Right- click IPv4 and choose New Multicast Scope. The New Multicast Scope Wizard appears. Click the Next button on the welcome page.
- In the Multicast Scope Name page, name your multicast scope (and add a description if you’d like). Click Next.
- The IP Address Range page appears. Enter a start IP address of 224.0.0.0 and an end IP address of 224.255.0.0. Adjust the TTL to 1 to make sure that no multicast packets escape your local network segment. Click Next when you’re finished.
- The Add Exclusions page appears; click Next.
- The Lease Duration page appears. Since multicast addresses are used for video and audio, you’d ordinarily leave multicast scope assignments in place somewhat longer than you would with a regular unicast scope, so the default lease length is 30 days (instead of 8 days for a unicast scope). Click Next.
- The wizard asks you if you want to activate the scope now. Click the No radio button and then the Next button.
- The wizard’s summary page appears; click Finish to create your scope.
- Verify that your new multicast scope appears in the DHCP snap-i n.
Setting Multicast Scope Properties
Once you create a multicast scope, you can adjust its properties by right- clicking the scope name and selecting Properties.
The Multicast Scope Properties dialog box has two tabs. The General tab allows you to change the scope’s name, its start and end addresses, its Time To Live (TTL) value, its lease duration, and its description— in essence, all the settings you provided when you created it in the first place.
The Lifetime tab allows you to limit how long your multicast scope will be active. By default, a newly created multicast scope will live forever, but if you’re creating a scope to provide MADCAP assignments for a single event (or a set of events of limited duration), you can specify an expiration time for the scope. When that time is reached, the scope disappears from the server but not before making all of its clients give up their multicast address leases. This is a nice way to make sure that the lease cleans up after itself when you’re finished with it.
Integrating Dynamic DNS and IPv4 DHCP
DHCP integration with Dynamic DNS is a simple concept but powerful in action. By setting up this integration, you can pass addresses to DHCP clients while still maintaining the integrity of your DNS services.
The DNS server can be updated in two ways. One way is for the DHCP client to tell the DNS server its address. Another way is for the DHCP server to tell the DNS server when it registers a new client.
Neither of these updates will take place, however, unless you configure the DNS server to use Dynamic DNS. You can make this change in two ways:
■ If you change it at the scope level, it will apply only to the scope.
■ If you change it at the server level, it will apply to all scopes and superscopes served by the server.
Which of these options you choose depends on how widely you want to support Dynamic DNS; most of the sites I visit have enabled DNS updates at the server level.
To update the settings at either the server or the scope level, you need to open the scope or server properties by right- clicking the appropriate object and choosing Properties. The DNS tab of the Properties dialog box (see Figure 6.20) includes the following options:
FIGURE 6.20 DNS tab of the scope’s IPv4 Properties dialog box

Enable DNS Dynamic Updates According To The Settings Below This option controls whether this DHCP server will attempt to register lease information with a DNS server. It must be selected to enable Dynamic DNS.
Dynamically Update DNS A And PTR Records Only If Requested By The DHCP
Clients This radio button (which is on by default) tells the DHCP server to register the update only if the DHCP client asks for DNS registration. When this button is active, DHCP clients that aren’t hip to DDNS won’t have their DNS records updated. However, Windows 7, Windows 8/8.1, Windows 10/11, Server 2003/2003 R2 and above DHCP clients are smart enough to ask for the updates.
Always Dynamically Update DNS A And PTR Records This option forces the DHCP server to register any client to which it issues a lease. This setting may add DNS registrations for DHCP- enabled devices that don’t really need them, such as print servers. However, it allows other clients (such as macOS, Windows NT, and Linux machines) to have their DNS information automatically updated.
Discard A And PTR Records When Lease Is Deleted This option has a long name but a simple function. When a DHCP lease expires, what should happen to the DNS registration? Obviously, it would be nice if the DNS record associated with a lease vanished when the lease expired. When this option is selected (as it is by default), that’s exactly what happens. If you deselect this option, your DNS will contain entries for expired leases that are no longer valid. When a particular IP address is reissued on a new lease, the DNS will be updated, but in between leases you’ll have incorrect data in your DNS— something that’s always best to avoid.
Dynamically Update DNS A And PTR Records For DHCP Clients That Do Not Request Updates This option lets you handle these older clients graciously by making the updates using a separate mechanism.
In Exercise 6.8, you will enable a scope to participate in Dynamic DNS updates.
EXERCISE 6.8
Enabling DHCP- DNS Integration
- Open the DHCP snap- in by selecting Administrative Tools ➢ DHCP.
- Right- click the IPv4 item and select Properties.
- The Server Properties dialog box appears. Click the DNS tab.
- Verify that Enable DNS Dynamic Updates According To The Settings Below is selected and that Dynamically Update DNS A And PTR Records Only If Requested By The DHCP Clients is also selected.
- Verify that the Discard A And PTR Records When Lease Is Deleted option is selected. If it’s not, then select it.
- Click OK to apply your changes and close the Server Properties dialog box.
Leave a Reply