Ever since I was able to give my IP Phone the correct time by NTP using the DHCP server, I’ve been playing around with the DHCP options to see if more is possible.

DHCP uses options in it’s packets to specify information. Each option specifies one specific piece of information. I’m going to list these most important options and explain them below. For a full list, see this site. The RFC is even more detailed if you’re in for a read.

  • 53 – DHCP message type (Discover, Offer,…).
  • 50 – Requested IP address: sometimes present in the Discover, always in the Request.
  • 55 – Parameter request list: used in the Discover only, requested options. Usually 1,3,15 and 6.
  • 1 – Subnet mask: must be specified before option 3.
  • 3 – Default router or gateway: more than one can be specified but this is rarely done.
  • 51 – Lease time: offered, or requested.
  • 54 – DHCP server: this is to specify which DHCP server is being negotiated with.
  • 6 – DNS server: commonly used but not required. More than one can be specified.
  • 15 – Domain name: also not required, but useful information in a domain.

Note that the above order is the order in which the options are presented in DHCP packets. Besides these commonly used options, other, less frequently used also exist:

  • 31 – Router discovery flag: see RFC 1256, makes IPv6-like ICMP router discovery possible.
  • 42 – NTP Server: more than one can be specified too here.
  • 60 – Vendor Class Identifier: used in Discover and Request to inform about the type of device.
  • 66 – TFTP server(s). This is useful for IP Phones, but some use option 150 instead.
  • 121 – Classless static routes. Classful static routes are option 33, deprecated.
  • 138 – CAPWAP controller address for Lightweight Access Point deployments (wireless). RFC 5417.
  • 150 – TFTP server(s). For IP Phones.

These options provide some centralised management of network services in a company. For example, in a voice VLAN, adding option 42 (NTP) and 150 (TFTP) will allow the IP Phones to display the correct time and receive firmware upgrades and other configuration settings from a TFTP server. Option 138 does the same for Lightweight Access Points, when using a large wireless infrastructure: the LAP is connected, receives an IP and controller address, downloads firmware and settings, and starts working.

I’m going to explain option 121 a bit more. Again, for a full read, see RFC 3442. Each client device has a routing table, just like a router.  On Windows, you can see this routing table with the ‘netstat -r’ command in the command line. Using option 121, you can add extra routes besides the default route to a device. The exact format is:

  • Eight bits for the prefix mask (since the maximum mask is 32, only six bits will be used).
  • Depending on the mask, a number of bits for the network prefix.
  • 32 bits for the next hop IP.
  • Multiple routes can be added, so after this another route can follow.

For example, in my home network, my computer is hooked up to a leyer 3 switch (the 3560), which connects to the gateway router, and one ethernet cable running to my home lab. My computer is in the subnet. Say I use the subnet in my home lab, with the 3560 at doing the routing. If I want to ping from my computer, the packet will be sent to the default gateway: the ISP router at, which will then forward it towards the ISP where it is dropped. However, if I can configure a static route to, it will work again.

Since my DHCP server is also a Cisco device, I can add the option in the command line (though any DHCP server, Windows or Linux, will allow it too of course):

Router(config)#ip dhcp pool LANPOOL
Router(dhcp-config)#option 121 hex 080AC0A8A805

Why the hex ‘080AC0A8A805’? I’ll break it down for you. 08: the /8 subnetmask. 0A: 10, the network address part of, and finally hex C0A8A805 translates to Note that for, next hop, the hex string would be ‘180A0000A8A805’. This string is longer because 24 network bits are required, not 8.

Now my pings to succeed, and when doing a ‘netstat -r’ on the Windows computer, I can see a route to in the routing table. This way, you can already start influencing traffic flows at the end devices. Whether that’s a smart choice, I’ll leave open for discussion.

PS. I know I’m spamming links to RFC documents, but in the networking world, if there’s any source you can trust, it’s a RFC, because vendors may stray from it.