That's correct. The response to a relayed DHCP Inform must (if it is possible) be unicast directly to the client. *BUT* if you are using a relay with separate address spaces, this will not work (the client will not receive the reply), as explained below: Note very carefully that a DHCPv4 server will send replies directly to a DHCPv4 client by way of 'ciaddr' even if the DHCPINFORM message was relayed. Note that this means DHCPINFORM processing is intentionally broken in deployments where the client's address space is unreachable by the DHCPv4 server. (see https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06) -----Message d'origine----- De : Freeradius-Users [mailto:freeradius-users-bounces+nicolas.chaigneau=capgemini.com@lists.freeradius.org] De la part de amindomao Envoyé : mercredi 25 février 2015 21:31 À : FreeRadius users mailing list Objet : Re: dhcp INFORM flooding
If that’s what ISC DHCP is doing, I’m all for it. There’s no RFC, which makes it a little difficult to know what’s the “right” thing to do.
I've read "https://tools.ietf.org/html/draft-ietf-dhc-dhcpinform-clarify-06" carefully and found this:
Next, the DHCPv4 server MUST determine the "reply address and port" according to the first of the following conditions it finds a valid reply address for, in order:
1. If the 'ciaddr' field is non-zero, the server selects its contents as an IPv4 address and port 68 ('DHCP client').
2. If the 'giaddr' field is non-zero, the server selects its contents as an IPv4 address and port 67 ('DHCP server').
3. If the IPv4 source address field is non-zero, the server selects its contents as an IPv4 address and port 68 ('DHCP client')
4. The server selects the limited broadcast address (all-ones) and port 68 ('DHCP client').
At this point, the DHCPv4 server verifies that it holds configuration authority over the reply address (or link in case of limited broadcast address) it has selected to transmit the reply to. If the server has not been configured to hold authority over this address, it MUST NOT reply. It SHOULD increment a counter visible to the operator but SHOULD NOT log an error (unless a mechanism is used to suppress repeated log messages). See the Security section (Section 5) for the rationale behind this direction.
Note very carefully that a DHCPv4 server will send replies directly to a DHCPv4 client by way of 'ciaddr' even if the DHCPINFORM message was relayed. Note that this means DHCPINFORM processing is intentionally broken in deployments where the client's address space is unreachable by the DHCPv4 server. In such cases, the server should probably be configured not to reply to DHCPINFORMs.
So, I think I'm right. I don't have a working isc-dhcpd now, but in one or two days I'll find it and test this thing. My clients flooding FR with DHCP-Informs and I want to shut their win7's up. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.