Subject: [Q]: dhcpinform packets

From: Shiva Shenoy <[email-masked]>
Date: Tue, 19 Jan 1999 14:29:18 -0500 (EST)

I have a network where dhcp requests are relayed through a Relay
Agent to a DHCP server. Occasionally the client sends
DHCPINFORM packets. (I do not know if these DHCPINFORM
packets are being unicast to the the DHCP server or brodcast)
>From the trace captured on the side of the DHCP server, I see that
these DHCPINFORM packets arrive at the server with the giaddr
field stamped with the address of the relay agent. 

According to RFC2131, the server should unicast the packet
to the address in 'ciaddr'.  However from the packet trace, I see
that the ACKs are being unicast to the relay agent. These ACKs
never make it back to the client.

Questions:
1. Are clients required to send the DHCPINFORM packets unicast 
   to the server ? Or should they be broadcast ?
2.  Has anybody seen implementations of dhcp servers which     
     behave as described above ?

Thanks,
-SS
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Rob Stevens <[email-masked]>
Date: Tue, 19 Jan 1999 17:36:00 -0500 (EST)

>field stamped with the address of the relay agent. 

They must be broadcast. The relay agent would not insert giaddr
on a unicast packet. (And in fact it might not insert giaddr even
on a local broadcast packet, dropping it instead).
>never make it back to the client.

Yes. According to rfc1542 (Wimer) the server should unicast back
to ciaddr if it is non-zero without regard to the value in giaddr.
I must confess that our server does not do this: it looks at giaddr
first. I think this is because we had some problems early on with
clients setting ciaddr improperly (when they were not willing to respond
to ARP)
>   to the server ? Or should they be broadcast ?

I think it is a grey area. It makes sense to broadcast, because
then only the relay agents need know where the server are.

>     behave as described above ?

Perforce, yes.

---

From: Shiva Shenoy <[email-masked]>
Date: Tue, 19 Jan 1999 17:38:39 -0500 (EST)

Rob, 

In such a case, ( where the server unicasts the ACK back to the
relay agent, instead of the client), the relay agent has no easy way
to distinguish between the ACK for the DHCPINFORM packet and
other ACKs.

Should the relay agent drop this ACK since the 'yiaddr' is
zero ?  If not, should the relay agent interpret the 'ciaddr' and
unicast it to this address ?

Thanks for the answer.

-
SS

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 20 Jan 1999 12:41:11 -0500 (EST)

>clients setting ciaddr improperly (when they were not willing to respond

Interesting...

In RFC 2131, page 23, 4th full paragraph:

"If the 'giaddr' field in a DHCP message from a client is non-zero,
the server sends any return messages to the 'DHCP server' port on
the BOOTP relay agent whose address appears in 'giaddr'.  If the
'giaddr' field is zero and the 'ciaddr' field is non-zero, then
the server unicasts DHCPOFFER and DHCPACK messages to the address in
'ciaddr'. ..."

This might explain why your server looks at giaddr first, as does
ours.

Cheers -- Kim

---

From: "Richard Letts" <[email-masked]>
Date: Sat, 23 Jan 1999 14:21:50 -0500 (EST)

> then only the relay agents need know where the server are.

DHCPinform is used by client to elicit further information from the dhcp
server. the client already needs to keep track of where it obtained its
lease from. HOWEVER the DHCPinform doesn't need to obtain the information
from the same sever that gave it its address. IMHO broadcast is the better
option for DHCPinform packets.

(an example of this would be where a ISC DHCP server tells a winNT+NW5
client what its IP address is, but a NetWare5 DHCP server tells the client
which tree and which context to use.. will this work? I'll know in a
cuople of weeks when I try it in practice)

Richard Letts                           mail:   [email-masked]
Network Services Manager                phone:  +44 161 295 5252
University of Salford                   fax:    +44 161 295 5888
Great Britain                           mobile: +44 385 275394