0

is there a way to tell the Windows DHCP-Client not to send along this useless UID parameter with its DHCP requests?

Thing is: We have dual boot machines (Windows and Linux). When Windows gets started first it gets the lease based on a UID that it sends along. Subsequent Linux DHCP requests get a new lease because the DHCP client there - as the rest of the world excluding Windows - doesn't send a UID. The DHCP protocol allows this and if there's a lease with UID, it's preferred and the MAC address isn't even considered.

Our DHCP server has a configuration option to ignore the UID and handle requests only based on the mac address. This however is a violation of the DHCP protocol and therefor I would really be painfull to change this, even though it would most probably not do any harm.

A quick google search held nothing but one mailing list / forum conversation in which some Microsoft guy actually told the topic starter to fiddle with the DHCP server or to reconfigure the DCHP clients to send the same UID as Windows does.

luxifer
  • 177
  • 1
  • 3
  • 12
  • I understand your question but I'm not understanding the actual problem that you're trying to solve. Is it that the Windows DHCP client obtains the same ip address on startup that it previously had, due to the client identifier? – joeqwerty Jun 07 '11 at 12:29
  • 1
    @Joe, he thinks that both Windows and Linux should get the same IP on the same hardware. He's apparently under the impression that a "Client" is the hardware itself, instead of the DHCP Client Software. – Chris S Jun 07 '11 at 12:52
  • @Chris: that's not true. again: All I want is to stop windows from sending the UID with a dhcp request. it has to send chaddr - which should be unique - anyway. a client MAY send a UID value so this should clearly be at the discretion of the person who manages the client. – luxifer Jun 07 '11 at 13:25
  • 3
    "this should clearly be at the discretion of the person who manages the client" -- I don't think this is "clearly" the case at all. If we're going to talk about what the RFC means, then "MAY" doesn't mean "It must be an end user option", it means "it's up to you, person using this spec to code your utility. go nuts" – Rob Moir Jun 07 '11 at 13:29
  • right... the RFC's talking about "vendors". still in every other os on the planet that comes with a dhcp client the admin can configure this... what's so hard in telling if it's possible with windows and if yes, how, anyway? – luxifer Jun 07 '11 at 13:46

5 Answers5

3

I don't understand the "painful" part (mostly where exactly its going to cause pain). I am assuming that UID stands for "unique identifier". The MAC address IS a unique identifier and a duplicate is something you will rarely if ever see. There is no harm in doing this.

SpacemanSpiff
  • 8,733
  • 1
  • 23
  • 35
  • "This however is a violation of the DHCP protocol" - that's the pain... RFC 2131 is very clear about this: "If the client supplies a 'client identifier', the client MUST use the same 'client identifier' in all subsequent messages, and the server MUST use that identifier to identify the client. If the client does not provide a 'client identifier' option, the server MUST use the contents of the 'chaddr' field to identify the client." ... notice the "MUST"? – luxifer Jun 07 '11 at 12:22
  • You're leaving out the "or else". What exactly will happen if the only unique identifier is the MAC address? – SpacemanSpiff Jun 07 '11 at 12:24
  • You could also just move to a larger subnet, and not worry about this. – SpacemanSpiff Jun 07 '11 at 12:25
  • I think what he means is that Windows and Linux generate different UIDs, and he's unhappy that the same physical box will get two different IPs (one for each OS). What he missed is that a Client in DHCP is the OS (more specifically the DHCP Client Software in each OS), not the physical hardware. This behavior is by design. – Chris S Jun 07 '11 at 12:31
  • again: it's bad practise... ""MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification." - there may be other systems that rely on this specification... imagine an installation that's indeed configured with a custom uid. then it gets a new nic; expected result: gets its lease back, actual result: gets new lease (and therefore incorrect dns entry)... I can't know our whole network, you know? – luxifer Jun 07 '11 at 12:39
  • @Chris: no. linux doesn't generate a uid. the boxes are dualboot and the dhcp server registers the hostnames in dns... but with a new lease it sees the hostname as already taken as long as the old lease is valid (windows doesn't free the lease on shutdown either) and adds a random string to it, rendering it useless... so either I get to know how exactly windows generates these UIDs or I get to know how to stop it from doing it at all – luxifer Jun 07 '11 at 12:41
  • 1
    @luxifer, you have two different OSes, just because they're on the same physical hardware does not make them the same DHCP Client or DNS Host (they should be different, though nobody's forcing you to not have conflicting settings). Windows will issue the same UID every time (until something changes), I don't see how that violates RFC2131. Your two OSes are not the same, see my comment above. Again, this behavior is **by design**. – Chris S Jun 07 '11 at 12:48
  • @Chris: I wrote that it would violate the RFC to tell the DHCP server to ignore the UID and use only MACs for identification. And a Client doesn't have to send a UID... actually no OS I can think of does this by default, except for windows... – luxifer Jun 07 '11 at 12:55
  • @SpacemansSpiff: what has the size of the subnet to do with this? – luxifer Jun 07 '11 at 12:55
  • 1
    @Luxifer, There's nothing wrong here. Windows and Linux are two different OSes and have two different clients. The DHCP Server *should* respond to each client independently. This is the correct behavior. You are trying to convince the DHCP Server that two different clients are the same (which they are not). – Chris S Jun 07 '11 at 12:57
  • If I ran Mac OS X an dLinux or BSD and Linux or Anything(tm) and Something Else(tm) that is NOT Windows, both OSes would appear as the same client to the DHCP server. After all it should be the admins choice whether to use that UID field or not... – luxifer Jun 07 '11 at 13:05
  • From the RFC: "The client MAY include a different unique identifier in the 'client identifier' option" and ""MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item." Now show me where the RFC states that different OSes on the same machine SHOULD or even MUST appear differently in their DHCP requests – luxifer Jun 07 '11 at 13:06
  • 5
    It appears what you're after is called Static IP's. It resolves your issue entirely. – ITHedgeHog Jun 07 '11 at 13:07
  • 1
    You still haven't said what will happen if you're not RFC compliant, or why this is actually a problem? I don't engineer my networks to be RFC compliant, I engineer them to WORK. – SpacemanSpiff Jun 07 '11 at 13:28
  • @SpacemanSpiff: I did. 52 mins ago. – luxifer Jun 07 '11 at 13:31
  • 1
    @Luxifer, the RFC clearly states that the implementation MAY send a UID; it clear does not state if this will be a configurable option. Therefor an implementation may or may not implement it, and if it is implemented the implementation may or may not make it user configurable. All of this conforms to the RFC so far. You may not like it, but it is the way it was designed (and purposely so at that). – Chris S Jun 07 '11 at 13:40
  • @Chris S: right. but the question was whether there's a way to configure this behaviour under windows or not. and that question's yet to be answered. – luxifer Jun 07 '11 at 13:48
  • @luxifer- it is not the admins choice to use the client identifier field, it's up the DHCP client. To put it in the other perspective, why doesn't the llinux client allow you to set the UID if it's the admins choice. Windows allows you to configure the UID. – Jim B Jun 07 '11 at 13:53
  • linux let's you, too... but if it's possible to stop windows from using it, it's less bothersome than to set a unique (per machine) one for windows and linux. it's one additional step after restoring an image that could be avoided if it was possible to stop windows from using it – luxifer Jun 07 '11 at 14:32
3

This behavior of windows is by design and in accordance with the spec. Until the linux DHCP clients come up to 2131 spec (it's only been 15 years which is nothing in *nix time) your best bet is to set your DHCP server to ignore the client identifier and instead rely on the chaddr field (essentially reverting it to rfc 1541 behavior). You cannot remove the UID field from the windows client.

Jim B
  • 23,938
  • 4
  • 35
  • 58
  • the spec says it MAY be used so I don't see where linux DHCP clients violate the spec by not using it by default... and again: I don't know if there are hosts in our network, which rely on compliance to this very part of the spec... you also don't say whether it's possible to configure under windows or not – luxifer Jun 07 '11 at 13:51
  • 2
    they are not *out* of compliance with the spec, they have simply not implemented an essential piece. UIDs were introduced to solve problems with mac addresses and DHCP ( I believe it was a uniqeness issue in large networks IIRC that was primary). UIDs were left optional because of legacy clients and since once you start using one, you should be using it every time, there isn't really an issue. Leases for the UID using systems should get reassigned to the UID using systems and non UID using systems use mac addresses. – Jim B Jun 07 '11 at 14:00
  • i know... that's what i already said... all i want is to prevent windows from using a uid at all... btw: pxe doesn't use uids either (even if you'd like to) and pxe is younger than rfc 2131 – luxifer Jun 07 '11 at 14:34
  • correct PXE doesn't use UIDs and currently has no plans to get the spec updated - since for pxe it doesn't matter – Jim B Jun 07 '11 at 15:22
  • 2
    To be fair on Unix and Linux: After almost a year of pushing from Philip A. Prindeville, the default in RedHat's RawHide is for `dhclient` to be configured with `send dhcp-client-identifier = hardware;` as the default in `/etc/dhcp/dhclient.conf`. See [RedHat Bug #560361](https://bugzilla.redhat.com/show_bug.cgi?id=560361). M. Prindeville also debunks the nonsense that luxifer is propounding here, saying "[actually **most** DHCP clients (HP printers, iPhones, Windows, Symbian phones, etc) **all** use a client-id](http://lists.fedoraproject.org./pipermail/users/2010-January/365253.html) ...". – JdeBP Jun 07 '11 at 16:18
2

is there a way to tell the Windows DHCP-Client not to send along this useless UID parameter with its DHCP requests?

No

Chris S
  • 77,337
  • 11
  • 120
  • 212
  • having waded through [**this**](http://www.google.co.uk/search?hl=&q=windows+dhcp+client+disable++UID&sourceid=navclient-ff&rlz=1B3GGLL_en-GB___GB433&ie=UTF-8#sclient=psy&hl=en&rlz=1B3GGLL_en-GB___GB433&source=hp&q=windows+dhcp+client+disable++UID+sending&aq=f&aqi=&aql=&oq=&pbx=1&bav=on.2,or.r_gc.r_pw.&fp=eb847c1bda400d6d&biw=1280&bih=903) I think you're right – user9517 Jun 07 '11 at 14:10
  • i also found this but it's 5 years old information... there may have been the remote chance that this situation had changed in the meantime... – luxifer Jun 07 '11 at 14:37
2

This is possible for Windows 8.1 with the November 2014 update rollup and Windows 10: https://support.microsoft.com/en-us/kb/3004537

Jan Klos
  • 44
  • 2
0

Our DHCP server has a configuration option to ignore the UID and handle requests only based on the mac address. This however is a violation of the DHCP protocol and therefor I would really be painfull to change this, even though it would most probably not do any harm.

I would put that rule in the category of crossing a deserted street a few meters left a pedestrian crossing.

If the client is not sending an UID or the server is ignoring it should make no difference in my opinion. The windows client asks for an IP and gets one. How can it tell on which grounds the server selects it?

Also, it is much easier to change one server than all the clients.

Lenne
  • 917
  • 1
  • 12
  • 30