Dynamic Host Configuration Protocol

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.

Domain Naming System (DNS)

 Domain Name System (DNS)

A DNS server is any computer registered to join the Domain Name System. A DNS server runs special-purpose networking software, features a public IP address, and contains a database of network names and addresses for other Internet hosts.

-> DNS Root Servers
DNS servers communicate with each other using private network protocols. All DNS servers are organized in a hierarchy. At the top level of the hierarchy, so-called root servers store the complete database of Internet domain names and their corresponding IP addresses. The Internet employs 13 root servers that have become somewhat famous for their special role. Maintained by various independent agencies, the servers are aptly named A, B, C and so on up to M. Ten of these servers reside in the United States, one in Japan, one in London, UK and one in Stockholm, Sweden.




-> DNS and the World Wide Web
All public Web sites run on servers connected to the Internet with public IP addresses. The Web servers at myip.com, for example, have addresses like 207.241.148.80. Although people can type address information like http://207.241.148.80/ into their Web browser to visit sites, being able to use proper names like http://www.myip.com/ is much more practical.

The Internet utilizes DNS as a worldwide name resolution service for public Web sites. When someone types a site's name into their browser, DNS looks up the corresponding IP address for that site, the data required to make the desired network connections between Web browsers and Web servers.

-> DNS Servers and Name Hierarchy
DNS uses a client/server network architecture. DNS servers are the computers designated to store DNS database records (names and addresses), while clients of the DNS include PCs, phones and other devices of end users. DNS servers also interface with each other, acting as clients to each other when needed.


   The DNS organizes its servers into a hierarchy. For the Internet, so-called root name servers reside at the top of the DNS hierarchy. The Internet root name servers manage DNS server information for the Web's top-level domains (TLD) (like ".com" and ".uk"), specifically the names and IP addresses of the original (called authoritative) DNS servers responsible for answering queries about each TLD individually. Servers at the next lower level of the DNS hierarchy track second-level domain names and addresses (like "about.com") , and additional levels manage Web domains (like "compnetworking.about.com").

DNS servers are installed and maintained by private businesses and Internet governing bodies around the world. For the Internet, 13 root name servers (actually redundant pools of machines around the world) support the hundreds of Internet top-level domains, while About.com provides authoritative DNS server information for the sites within its network. Organizations can similarly deploy DNS on their private networks separately, on the smaller scale.

-> Configuring Networks for DNS
DNS clients (called resolvers) wanting to use DNS must have it configured on their network. Resolvers query the DNS using fixed (static) IP addresses of one or more DNS servers. On a home network, DNS server addresses can be configured once on a broadband router and automatically picked up by client devices, or the addresses can be configured on each client individually. Home network administrators can get valid DNS server addresses from either their Internet service provider or third-party Internet DNS providers like Google Public DNS and OpenDNS.


-> Types of DNS Lookups
IP address lookup is the process of translating between IP addresses and Internet domain/computer names. Forward IP address lookup converts an Internet name to an address. Reverse IP address lookup converts the number to the name.



Several Internet services support both forward and reverse IP lookup for public addresses. On the Internet, these services rely on the Domain Name System (DNS) and are known as DNS lookup and reverse DNS lookup services.

Years ago, before the advent of dynamic IP addressing, many smaller business networks lacking name servers managed private IP lookups through hosts files. Hosts files contained simple lists of static IP addresses and associated computer names. This IP lookup mechanism is sitll used on some Unix computer networks. It can also be used on home networks without a router and with static IP addressing in place. DHCP-based networks, like most home networks today, rely on the DHCP server to maintain hosts files.

Utility programs provided with the computer's network operating system (NOS) allow IP address lookups on both private LANs and the Internet. In Windows, for example, the nslookup command supports lookups via name servers and/or hosts files.

-> DNS Caches
To better process high volumes of requests, the DNS utilizes caching. DNS caches store local copies of recently-accessed DNS records while the originals continue to be maintained on their designated servers. Having local copies of DNS records avoids having to generate network traffic up and through the DNS server hierarchy. However, if a DNS cache becomes outdated, network connectivity issues can result. DNS caches have also been prone to attack by network hackers.

-> Dynamic DNS
Standard DNS requires all IP address information stored in the database to be fixed. This works fine for supporting typical Web sites but not for devices using dynamic IP addresses such as Internet Web cams or home Web servers. Dynamic DNS (DDNS) adds network protocol extensions to DNS to enable name resolution service for dynamic clients.

Unlike DNS that only works with static IP addresses, DDNS is designed to also support dynamic IP addresses, such as those assigned by a DHCP server. That makes DDNS a good fit for home networks, which often receive dynamic public IP addresses from their Internet provider that occasionally change.

To use DDNS, one simply signs up with a DDNS provider and installs network software on their host to monitor its IP address. For example, dyndns.com provides a free dynamic DDNS service via software that can run on Windows, Mac or Linux computers.

-> DNS Blacklists
A DNS blacklist (DNSBL) is a database that contains the IP addresses of malicious hosts on the Internet. These hosts are typically email servers that generate large volumes of unsolicited mail messages (spam) or other Internet servers used for network attacks. A DNSBL tracks servers by IP address and also within the Internet Domain Name System (DNS).


DNS blacklists help you to determine whether message senders may be spammers or hackers. You can also report spam and suspicious addresses to a DNSBL for the benefit of others on the Internet.


-> DNS Record's
Computers that need to be accessed from Active Directory and DNS domains must have DNS records. Although there are many different types of DNS records, most of these record types aren't commonly used. So rather than focus on record types you probably won't use, let's focus on the ones you will use:

  •     A (address) Maps a host name to an IP address. When a computer has multiple adapter cards or IP addresses, or both, it should have multiple address records.

For example, if you want mycomputer.yourdomain.com to point to your home computer (which is, for example, 192.168.0.3), you would enter a record that looks like:

mycomputer.yourdomain.com. A 192.168.0.3

Important: You must put a period after the hostname. Do not put periods after IP.
  •     CNAME (canonical name) Sets an alias for a host name. For example, using this record, zeta.microsoft.com can have an alias as www.microsoft.com.

For example:

yourdomain.com. A 192.168.0.1

Using CNAME, you can point other hostnames to the canonical (A record) address. For example:

ftp.yourdoman.com. CNAME yourdomain.com.
mail.yourdomain.com. CNAME yourdomain.com.
ssh.yourdomin.com. CNAME yourdomain.com.

CNAME records make it possible to access your domain through ftp.yourdomain.com, mail.yourdomain.com, etc. Without a proper CNAME record, you will not be able to connect to your server using such addresses.
  •     MX (mail exchange) Specifies a mail exchange server for the domain, which allows mail to be delivered to the correct mail servers in the domain.

  •      NS (name server) Specifies a name server for the domain, which allows DNS lookups within various zones. Each primary and secondary name server should be declared through this record.

  •     PTR (pointer) Creates a pointer that maps an IP address to a host name for reverse lookups.

For example, to make 192.168.0.1 resolve to www.yourdomain.com, the record would look like:

    1.0.168.192.in-addr.arpa PTR www.yourdomain.com.

Note: The IP address is reversed in the first field. Please use a period after your hostname (second field).

The �in-addr-arpa� method is the most frequently used.

Important: PTR records are effective only if your site has its own IP address.

Important: PTR records are only effective if named.conf is manually edited and the proper zone information is added. This can only be done by a root user (the server Admin).
  •      SOA (start of authority) Declares the host that's the most authoritative for the zone and, as such, is the best source of DNS information for the zone. Each zone file must have an SOA record (which is created automatically when you add a zone).