Srinivas sent me the following printout a few days ago and asked me whether I could explain the weird DHCP bindings (I removed the lease expiration column from the printout):

Switch#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Type
                    Hardware address/
                    User name
192.168.101.140     0152.4153.2000.188b.    Automatic
                    cfb7.f800.0000.0000.
                    00
192.168.101.141     0152.4153.2000.188b.    Automatic
                    cfb7.f800.0001.0000.
                    00

Sometimes it’s good if your programming history goes back to the days when we had to read hex dumps: the first few bytes of the Client ID immediately looked like uppercase letters follow by a space. Lookup into the ASCII tables (I still can’t read hex without external help) produced the string 'RAS ' and Google quickly provided the culprit: Microsoft RAS.

A Remote Access Server (RAS) obviously needs IP addresses for its dial-in clients. They could be in a separate pool, in which case RAS has to do routing (potentially including a routing protocol) and its administrator has to be able to configure that. Obviously that was too tough a choice for some people, so Microsoft decided to offer another approach: grab a few IP addresses from the DHCP server and pass them to the dial-in clients. Nothing wrong with that until you start using a “somewhat unusual” DHCP Client ID format.

Are they violating the standards? Strictly speaking, they’re not. RFC 2132 says:

[client identifier] MAY consist of a hardware type and hardware address. In this case the type field SHOULD be one of the ARP hardware types defined in STD2 [22]. A hardware type of 0 (zero) should be used when the value field contains an identifier other than a hardware address.

However, most other DHCP client implementations use hardware type zero when the subsequent bytes are not a MAC address. By needlessly violating the common behavior, you’re bound to trigger problems with some overly-zealous servers, which are working close to the sidelines of RFC 2132. Here’s what it has to say about the servers:

[client identifier] is expected to be unique for all clients in an administrative domain. Identifiers SHOULD be treated as opaque objects by DHCP servers.

Great wording, isn’t it? Clients don’t have to respect the common rules and servers are not required not to rely on the common behavior. As far as I remember, you can’t have your cake and eat it too ... unless we’re talking about digital goods, so maybe things are different in the RFC land.

Last but not least, what do you think: is there a specific reason Microsoft’s programmers chose to structure the RAS client identifiers the way they did or were they simply too sloppy to read the standards?