Class in Session: Cisco

In my last post, we learned that the Dynamic Host Configuration Protocol (DHCP) is a computer networking protocol used by hosts, identified as DHCP clients, to retrieve IP address assignments and other configuration information.

DHCP uses a client-server architecture. The client sends a broadcast request for configuration information. The DHCP server receives the request and responds with configuration information from its configuration database. In the absence of DHCP, all hosts on a network must be manually configured individually, which is a time-consuming and error-prone undertaking.

In this post, we will build on the previous explanation of the DHCP process and examine some of the special functions of DHCP servers, along with some of the security issues that must be addressed.

Normally, routers do not forward broadcasts. However, there are times when an exception to this rule would be useful. For instance, IP address assignment would be easier if you did not have to deploy a DHCP server on every network segment. If routers passed broadcasts, a central server could take care of remote locations.

The Cisco IOS allows routers to forward broadcasts through the ip helper-address command. When configured to do so, a router will forward broadcasts to predetermined remote locations using unique and predetermined UDP ports. A router configured to forward DHCP requests is called a DHCP relay. DHCP relays forward requests and set the gateway to the local router.

When first configured, the helper-address supports eight UDP ports. Broadcasts to these eight ports are forwarded to the remote address specified by the command. The ports are:

• NTP – UDP port 37
• TACACS – UDP port 49
• DNS – UDP port 53
• DHCP – UDP port 67 and 68
• TFTP – UDP port 69
• NetBIOS name service – UDP port 137
• NetBIOS datagram service – UDP port 138

Additional ports may be added using the command ip forward-protocol udp port.

As a word of caution, it must be noted that the DHCP process has a few security concerns that should always be addressed. A malicious user could cause a serious security breach by installing an unofficial or rogue DHCP server into your network.

The immediate problem would be a server passing out ip addresses and associated configurations that have already been statically assigned to another device. This causes the potential for two or more devices ending up with the same IP address. Here, the undesired result would be the possibility of intermittent operation of one device or the other.

Even more serious is the situation where a renegade DHCP server manages to get a client to accept its lease offering, and then feeds the client its own version of other booting parameters. One undesired scenario is when a client has been configured to load its operating system (OS) over the network via Trivial File Transport Protocol (TFTP). In this situation, the rogue DHCP server directs the client to a different file selected by the operator of the rogue server. In fact, the file could actually reside on a different server operated by the attacker.

In this scenario, the user would load a bogus OS that allows the perpetrator to take control of the client and provide back doors into the system and associated network. And, given that boot parameters are often used to control many different aspects of a computers’ operation and communication, many other highly undesirable scenarios are just as serious.

As a final thought, let’s return to the question originally posed, “Where Did That IP Address 169.254.0.1 Come From?” Many client operating systems use something called Automatic Private IP Addressing. This process assigns an IP address even in the absence of a DHCP server. If a DISCOVER message is not answered, the client picks a random 16-bit number and prepends it with 169.254.x.x. It performs a gratuitous ARP and assigns that address to itself.

The idea of Automatic Private IP Addressing is that two travelers could link their devices quickly and easily. For instance, two train commuters could play a game on the way to the city. They configure DHCP on their laptops and use Automatic Private IP Addressing on the train and then get a different IP in the office.

If you see a 169.254.x.x address, it means that the DHCP server is not reachable. The PC will not work because there is not a router to or from that PC. Troubleshoot this by finding out why the PC cannot see the DHCP server.

In my next blog, we shall revisit another old friend, the Domain Name System (DNS).

Author: David Stahl

In this post we will revisit an old friend that is used quite often in all of our modern networks, Dynamic Host Configuration Protocol (DHCP). The DHCP process allows a server to automatically provision IPv4 addresses, along with other important configurations, to clients as they boot up. The following processes take place when DHCP is implemented.

DHCP Discovery

The client broadcasts messages on the physical subnet asking for IP configuration information and to discover available DHCP servers. If required, the network administrators can configure a local router to forward DHCP packets to a DHCP server located on a different subnet. This client-implementation creates a User Datagram Protocol (UDP) packet with the broadcast destination of 255.255.255.255, or the specific subnet broadcast address.

A DHCP client can also request its last-known IP address. If the client remains connected to a network for which this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation-dependent timeout for the client to give up on the request and ask for a new IP address. Continue reading ‘DHCP Implementation Processes’

In this post we will revisit an old friend that is used quite often in all of our modern networks, Dynamic Host Configuration Protocol (DHCP). The DHCP process allows a server to automatically provision IPv4 addresses, along with other important configurations, to clients as they boot up.

There are two principle advantages to using a DHCP server in your network.

1. DHCP makes it easier to administer an IP network. Without the DHCP functionality, administrators would have to manually assign and track IP addresses, which is a process that is inherently labor intensive and, unfortunately, error-prone.
2. DHCP allows clients to temporarily use IP addresses and thus make better use of IP address space. For example, DSL customers of an ISP only need an IP address when they are currently online.

DHCP uses a client-server architecture. The client sends a broadcast request for configuration information. The DHCP server receives the request and responds with configuration information from its configuration database. DHCP automates network-parameter assignment to network devices from one or more fault-tolerant DHCP servers. Even in small networks, DHCP is useful because it can make it easy to add new machines to the network.

When a DHCP-configured client, such as a computer or any other network-aware device, connects to a network, the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses, along with other information about client configuration parameters. These additional parameters could include information such as the network default gateway, domain name, the DNS servers, and additional servers such as time servers. On receiving a valid request, the server assigns the computer an IP address with a lease, which is a length of time the allocation is valid. The query from the client is typically initiated immediately after booting and must be completed before the client can initiate IP-based communication with other hosts.

Continue reading ‘Revisiting an Old Friend: DHCP’