Dynamic Host Configuration Protocol(DHCP)
DHCP is a protocol intended to enable machines (servers, game consols, etc) wishing to be "online" the ability to request Internet Protocol information from a DHCP server automatically. Most home users actually have this set up as part of their home network whereby a home router (wired or wireless) is the DHCP server that manages your IP information, allocates it to those machines requesting Internet access (desktop, laptop, iPad, etc), and tracks that IP information in a small DHCP table. That was how it was done in IPv4. IPv6 is different and with enhanced protocols like Stateless Address Auto-configuration (SLAAC)2, DHCP concepts and best practices will also change.
In this article we will begin to outline some of the fundamental differences between the two versions, explore historical uses of DHCPv4 and how those concepts will adapt/change in IPv6.
Dynamic Host Configuration Protocol (DHCP) was first proposed in 1993 as an evolutionary step from the BootStrap Protocol (BOOTP) which required manual intervention to configure each node (clearly not a very scalable way for the Internet to grow). It was finalized and released for use in IPv4 in 1997 and continues to be the standard networking auto-configuration sequence for nodes establishing Internet connections. Much like most IPv4 paradigms, the world of IPv6 will change the way administrators deploy, manage and utilize DHCP as well as present opportunities to advance the "use" of DHCP as it stands today. This article will review the history of DHCPv4, explore how its use has evolved in many organizations (manly Enterprises), how DHCPv6 and Stateless Address Autoconfiguration (SLAAC) are to be used, and, finally, the fundamental differences between the two both in theoretical & practical application (hint: DHCP for most has become a very rudimentary asset tracking tool that was never the intent of the protocol itself).
The History of DHCPv4
As mentioned in the opening paragraph, DHCPv4 was a solution to the non-scalable manual network configurations needed by each node trying to access a network and the Internet. It has been around since 1993 and was finalized in 1997 and is used to this day by most all Internet users (even home users — your home router/base station performs DHCP). A very simplistic look at a typical DHCP set up helps to identify what DHCP does for most networks:
In this scenario (which scales out to the largest networks), the DHCP server acts as a sort of traffic cop who gives people the proper identification to access both local networks and the Internet at large. Simple configuration steps are followed by the "clients" (which can be anything with an Internet connection needing an IP address) to request proper IP address information thereby allowing the "client" to interact both locally (LAN) and across the Internet.
The "client", upon booting up, will send out a broadcast message to the local network (in the case of wireless networks, there is the extra step of identifying which network to connect to or SSID) seeking the DHCP server, announcing itself and requesting said IP Address information. That IP information is then handed out and stored in a very limited table much like this:
In the above table, one can keep track of Client Name, Interface, IP Address (these are 1918 address by the way which is a part of NAT — that goes away in IPv6 as everything will have a unique address), the Media Access Controller (MAC) number and Time To Live (TTL) information3. From this interface (or server) and administrator can review what is on the network, manage the IP information or access to any node on the network and review for changes — this is how many Enterprise Admins use DHCP today.
In a v6 world, while there is DHCPv6, there are a number of very systemic changes that will need to be understood by admins (and aspiring geeks) that will alter how you use networking protocols such as DHCP. First and foremost is the notion of scarcity (IPv4) versus unlimited (IPv6) address space. The v4 mind-set is about managing finite, scarce resources and why things like Network Address Translation were invented (as well as TTL in DHCPv4). Furthermore, Asset Tracking, which has been conflated as part of DHCPv4, will be discussed later in the article and is an opportunity to improve upon what is used today — however, Asset Tracking was never intended to be a part of the network layer and should be removed from the DHCP mind set.
DHCP in a v6 World!
IPv6 Addresses are 128bit in length and the intent is for EVERYTHING on line to have a unique IP address as well as allow the Internet to expand faster and faster by allowing devices to get online quickly and efficiently. This is where, in a v6 world, the notion of Stateless Address Auto-configuration comes in (we will get to DHCPv6 after this).
SLAAC is the protocol that enables each node that connects to a local area network (LAN), which in turn connects to the Internet via a router/gateway, the ability to self-configure its own Internet info (IP Address). Basically, if a node were to configure itself with an IPv4 address, which is ¼ the length of a full IPv6 address, and then request relevant "prefix" information from the Internet gateway/router, that node would then be online and ready to go. This greatly simplifies networking requirements and asset utilization (not really a need for DHCP servers in this scenario) and also changes how admins will use/deploy DHCP.
There is still a notion of DHCPv6 , which performs a near identical function as DHCPv4, yet the intent is for routers and switches to be requesting that space versus the end-nodes themselves. Thus, DHCP will, for most networks, no longer be a part of the "client" configuration sequence as SLAAC will take that over.
DHCPv4 will have to be supported for all dual stacked networks for years (7-10+ yrs), as v6 begins to be overlayed atop v4 networks, admins will have to rethink how they use DHCP in light of SLAAC and DHCPv6 differences.
DHCPv4 vs DHCPv6/SLAAC
For most ISPs today, the use of DHCP is a way to easily add IP information to oncoming nodes like end users at Comcast. DHCP has allowed organizations like Comcast to greatly speed up and enable end users simply to plug in pre-configured home gateways that spin up on the network, request IP information, and away they go into cyberspace. The notion of what the IP address is being used for is not relevant to most ISPs as they only are concerned with bandwidth constraints.
DHCP being used by everyone else, especially enterprises, has some different implications often conflated with Asset tracking. Enterprises and companies are concerned with what IP addresses are being used for, by whom and being able to keep some track of that information. In the case of a financial institution, there are Sarbanes-Oxley (SOX) requirements for keeping track of usage and being able to look thru historical data. In the case of hospitals or insurance companies it is the Health Insurance Portability & Accountability Act (HIPAA) that stipulates these requirements. In either scenario, and most other enterprise scenarios, DHCP has been dual tasked with both being the auto-configuration mechanism for nodes coming onto the network and very rudimentary Asset Tracking. In a v6 world, SLAAC and DHCPv6 will simplify the former but complicate the latter.
A brief interlude and thoughts on how this evolved: networking protocols as envisioned by Vint & Bob were for the network to be highly scalable and resilient. They never envisioned the Internet becoming the all inclusive information highway for all things personal as well as business related. Thus, users began to implement their own particular "best practices" and adapted the protocols given to them to suit their needs. This is what happened with DHCPv4.
DHCPv4 was always a pat of the networking side of things. It also had, at the core of IPv4, a problem of scarcity as it was known that the 4.3 Billion IP Addresses were finite and not going to last. So, DHCP as used by those other than ISPs evolved into part network protocol, part IP address mgmt tool, part asset tracker, and part forensic tool — while this may not have been the intent of DHCP, the clear need for those additional "features" is still very, very important!
As we've explained, in a v6 world with SLAAC & DHCPv6, the additional features developed a top DHCPv4 and used by many administrators will simply not be possible. This is OK and should be welcome for it allows the admin to clean up the networking side of things, simplify the architecture and develop true Asset Tracking tools at the same time (akin to getting rid of NAT which is only for IPv4).
As an example, the space known as DNS, DHCP, & IPAM (DDI) has spawned a number of successful companies who built their tools to manage IPv4 Addresses, allocate those addresses, keep track of them, and set up alarms for resource constraints as the supply of given IPs diminishes. In IPv6, you do not really need the last step as the 300 Trillion, Trillion, Trillion addresses will most likely not see constraints for the next 50 years. Furthermore, with SLAAC enabled, there is no need for a DHCP server (unless you are using DHCPv6 for your core and/or edge networks) and therefore the simplistic asset tracking capabilities will cease to be available — this requires rethinking how one approaches their network and systems management tasks.
Conclusions
There has been a lot of misconceptions surrounding DHCP, from what its original intent was to how it was being used by many companies and Enterprises. This article sought to identify the most common and explain why and where those ideas came from. In a v4 world, they were the right approaches to limited and scarce resources. As we move further away from v4 and into v6, mind sets will need to adapt to a world of infinite IP Addresses, better and more simplistic networking protocols and best practices, and develop alternative approaches to the amalgamated tools (asset tracking as a part of DHCP) that heretofore have been deployed in Enterprises and SMBs. While IPv4 is not going away any time soon, the conversion to IPv6 should help catalyze this new and exciting opportunity to improve not only your organization's Internet Infrastructure, it should also help to improve the entire Internet's performance itself.
Backup Exec Service is not getting started