DHCP servers can send vendor specific options to clients to granularly control configuration. Microsoft clients are out-of-the-box prepared to receive Microsoft Windows specific options while Microsoft DHCP servers have the ability to send DHCP options only received by Windows clients.

Some applications use the content of a DHCP option to receive configuration data, for example Microsoft Lync or RES Workspace Manager. Since this applications only run on Microsoft Windows its no more than logical to only send this option to Windows clients.

In this article I’ll explain how this mechanism works and how you can send Microsoft Windows specific DHCP options from a non-Microsoft DHCP server (like a Linux or Lucent-Alcatel VitalQIP appliance).

Vendor Classes

The vendor class is used by DHCP clients to optionally identify the vendor and configuration. Examples of vendor classes are:

• “Cisco Systems, Inc. IP Phone CP-7940” for a Cisco Unified IP Phone 7940G
• “alcatel.noe.0” for an Alcatel IP touch phone
• “MSFT 5.0” for all Windows 2000 clients (and up)
• “MSFT 98” for all Windows 98 and Me clients
• “MSFT” for all Windows 98, Me and 2000 clients

As you can see there’s no naming convention or regulation around the vendor class, but the implementation seems clear. Microsoft claimed three vendor classes where the “MSFT 5.0” is the most used since it overrules “MSFT” (and the market share of Windows 98 is around 0.01%).

 

Microsoft DHCP Server

In a Microsoft DHCP server the vendor classes for Windows Windows machines are built-in, others can be added via the context menu of the protocol stack (IPv4 or IPv6) and selecting Define Vendor Classes.

 

Microsoft Windows DHCP Client

In the first stage of a DHCP request, the DHCP Discover, a client adds the predefined vendor class in DHCP option 60 (or Vendor Class Identifier).

For Windows 2000 and above (Vista / 7 / 8 / etc.) “MSFT 5.0” is send. Since this is a broadcast all DHCP servers (and other machines sniffing the package) know this is a “Microsoft Windows 2000 client” and only DHCP options for this vendor should be sent.

PS: The default vendor class in your Microsoft Windows DHCP client can be changed to obfuscate your OS, but its unsupported – see this link.

 

DHCP Offer

After a DHCP server  receives a  DHCP Discover  it returns a  DHCP Offer  to the DHCP client containing the DHCP lease. The  lease contains IP information (the offered IP, relay agent, DHCP server), MAC addresses, options and some other stuff.

 

What’s interesting to know is that the DHCP server only returns the options the DHCP client requested via option 55 in its DHCP Discover packet. By default that’s: 1, 3, 6, 15, 31, 33, 43, 44, 46, 47, 121 and 249 (for explanation see IANA).

The DHCP option we’re interested in is option 43 Vendor Specific Information. As described above, the value of the DHCP option is only sent to clients that have a specific vendor class (MSFT 5.0 in the example) .

 

DHCP Option 43 – Vendor Specific Information

DHCP option 43 is described in RFC2132, it explains how the packet of the option needs to be send. The structure is pretty simple: the first byte contains the option code 43 [or 0x2B in hex], the second byte the length of the package followed by one or more options.

Each option in (i1, i2, etc) has same basic structure: the first byte contains the options code, the second byte the length of the package followed by the value of the option.

What’s not documented (clearly) in the RFC is that each option ends with a byte with value 0 (0x00) – a separator. That means that each option in (i1, i2, etc.) actually has the following structure:

Example

Here’s an example of how a vendor specific DHCP option diagram looks like.

In the example I’ve set three vendor specific options (with vendor class MSFT 5.0, for Windows 2000 clients).

• Option 10 with string value Ingmar
• Option 11 with string value Verheij
• Option 12 with string value www.ingmarverheij.com

By default only option 001, 002 and 003 are available for Microsoft Windows 2000 Options but these can be extended via the context menu of the protocol stack (IPv4 or IPv6) and selecting Set Predefined Options.

 

The values for the vendor specific options are set via the scope or server options, in this case I’ve configured them in the scope options.

DHCP Offer

The DHCP client receives the DHCP Offer including the specified vendor specific option (using DHCP Client Tool):

 

The DHCP offer received contains multiple options including subnetMask [1], domainName [15], domainNameServer [6] and the vendor specific option [43] just like in the example diagram is shown. What you can’t see is the DHCP option packet containing the code [43] and the length [43 bytes]. Wireshark does show this information.

What’s clear to see in both captures is that each option (i1, i2, etc) ends with a 0 (0x00) byte. Though this is not mentioned in the RFC they are required for the DHCP client to identify the end of the option allowing the client to separate the options.

The value is send as hexadecimal byte values. Translating the hex values to string can be done here and from string to hex here.

Read DHCP options from registry

You can also read the vendor specific DHCP options received by the client from the registry.:

I wrote a PowerShell script that reads the received DHCP options from the registry and can format them for you. The script can be found here.

 

Non-Microsoft DHCP servers

This information is especially valuable if you have to configure a non-Microsoft DHCP server which does not provide (Microsoft) vendor specific DHCP options by default.

 

Linux DHCP server

If you have a Linux DHCP server vendor specific options can be set in the /etc/dhcp/dhcpd.conf configuration file.The options can be set in a subclass where you can filter on the vendor class identifier. Below you can find an example configuration presenting the same vendor specific options as in previous examples.

dhcpd.conf

ddns-update-style none;

default-lease-time 600;
max-lease-time 7200;

option domain-name "domain.local";
option domain-name-servers 192.168.0.1;
option routers 192.168.0.1;

authoritative;
log-facility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
  range 192.168.0.100 192.168.0.200;
}

class "MSFT 5.0" {
   match if option vendor-class-identifier = "MSFT 5.0";
   option vendor-class-identifier "MSFT 5.0";
   option vendor-encapsulated-options 0a:07:49:6e:67:6d:61:72:00:56:65:72:68:65:69;6a:00:77:77:77:2e:69:6e:67:6d:61:72:76:75:72:68:65:69:6a:2e:63:6f:6d:00;
}

class "MSFT 98" {
   match if option vendor-class-identifier = "MSFT 98";
   option vendor-class-identifier "MSFT 98";
   option vendor-encapsulated-options 0a:07:49:6e:67:6d:61:72:00:56:65:72:68:65:69;6a:00:77:77:77:2e:69:6e:67:6d:61:72:76:75:72:68:65:69:6a:2e:63:6f:6d:00;
}

class "MSFT" {
   match if option vendor-class-identifier = "MSFT";
   option vendor-class-identifier "MSFT;
   option vendor-encapsulated-options 0a:07:49:6e:67:6d:61:72:00:56:65:72:68:65:69;6a:00:77:77:77:2e:69:6e:67:6d:61:72:76:75:72:68:65:69:6a:2e:63:6f:6d:00;
}

 

 

Alcatel-Lucent VitalQIP

As the vendor specific information is considered an opaque data type the user must define the option data in the raw format. With a VitalQIP appliance the vendor specific information can be provided in two ways:

1. DHCP Option Template – The vendor-specific information can be provided on the DHCP Option Template- Modify page. In the Active Options area, choose Vendor Specific Information, and enter the information in the Value field.  In order to include the controller IP addresses in the DHCP option 43 message, enter the information to the DHCP Option template in QIP as a single hex value: [ip hex]. In order to send more than one IP address with DHCP Option 43, enter the information to the DHCP Option template in QIP as a single hex value:[ip hex ip hex] and not [ip hex],[ip hex]. In this case, the comma in the middle causes problems for DHCP to parse the string passed from QIP. Source: cisco.com

 

2. User exit script – A place holder is set in the vendor specific DHCP option template, for instance [VENDOR-SPECIFIC-OPT1] which get replaced by a value via a user exit script (qipdhcpuserexit ). The user exit script reads a managed file (accessible via DNS > Managed Files) that contains the Hex value in [block quotes]. For example:

[VENDOR-SPECIFIC-OPT1]=[0a07496e676d617200566572686569;6a007777772e696e676d61727675726865696a2e636f6d00]

 

 

Creating the string

After reading this article you now know how to vendor specific DHCP options work and how you can configure them for a non-Microsoft DHCP server. I can imagine you don’t want to create the string for the options manually (neither do I) so created a small .NET application that does that for you.

The usage is straightforward: just add the options, specify a separator (or not) and click Generate.

Download

You can download the tool here: CreateVendorSpecificString.exe

 

 

.