dhcp INFORM flooding

[Chaigneau, Nicolas]

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 at 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.