DHCP Future - The Future of DHCP Service at Carnegie Mellon

Background

We currently support our own DHCP server. This server, (which was one of the first public domain DHCP servers), handles our current network architecture with very few problems. However, over the next few years, we are going to see some changes occur that will require our DHCP server for support:

IPv6 uses multicast to send and receive DHCP requests, while IPv4 uses the broadcast address. We will want to make sure that our DHCP server can hand out IPv6 addresses, and to do that, it will need to listen to the all-dhcp-servers multicast channel.
As we provide more and more routed subnets, we need a mechanism that will correctly support a machine that is registered for use in multiple subnets. Our current DHCP server assumes a hardware address is only ever in one subnet.
In the future, we may want to start to use dynamic addresses for specific subnets, and have the DHCP server take care of updating the DNS entries for these hosts. Our current server does not handle dynamic DNS operations.
The IETF is currently working on an official DHCP MIB, and we'd like to migrate away from our custom MIB to the official one. Once we use the official MIB, or support utilities will not only support our DHCP server, but it will also support anybody else's server that implements this MIB.

The Plan

This is a lot of development work to be done. After discussing the future of our DHCP server with others, we've decided to actually halt development on our server, and instead migrate to a public domain server provided by the Internet Software Consortium. (These are the same people that offer the BIND software we use on our DNS servers.)

In order to move to this software, we will need to SNMP instrument their DHCP server. We have experience with this type of work, and this will be the perfect test of our new AgentX software. Once instrumented, we can put this software into place, and offer the appropriate roaming operations across our subnets.

In addition to the new features, we will free up development resources that would have spent time adding required functionality to our server for work on other projects.

The Future

Once we've migrated to the ISC's DHCP server, we will be able to use their future releases, which will include support for:

Dynamic DNS Updates
DHCP Authentication (possibly)
Server to server protocol (for sharing dynamic pools)

However, our role in DHCP development will not end. While we are using somebody else's DHCP server, we will still be exploring new ways to use DHCP service to benefit users here at CMU. This work may include:

Support for Multiple IPs per MACAddr Based on DHCP Client Identifier

Some OS's offer the ability to run another OS within them. For example, there's a program that runs under MacOS which makes your mac behave like a PC running Win95. The second OS has full network capabilities, and requires it's own IP address. At this time, the only way to get another IP address for the secondary OS is to either have that OS use a different MACAddress (not always possible), or have it hardcode an IP address.

We do not want to have any IP addresses hardcoded on campus, so to us this is not a preferred IP assignment mechanism. We would like to explore the ability to have the DHCP server hand out a lease based on originating subnet, macaddr, and the client identifier within the DHCP packet.

If this worked, DHCP packets containing that machine's macaddress would be given different IP addresses based upon when it's using MacOS to boot, and when it's using Win9x to boot.

Ryan Troll ryan+@andrew.cmu.edu
May 1998