Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK

From: "Kostur, Andre" <[email-masked]>
Date: Mon, 5 Jan 2004 11:43:26 -0800

RFC 2131, section 4.1:

   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 nonzero, then the server
   unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
   set, then the server broadcasts DHCPOFFER and DHCPACK messages to
   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
   messages to the client's hardware address and 'yiaddr' address.  In
   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
   messages to 0xffffffff.

Thus, if there is a valid CIADDR in the client's request, the server's
reponse will be unicast back to that CIADDR.

> -----Original Message-----
> From: Kevin A. Noll [mailto:[email-masked]]
> Sent: Monday, January 05, 2004 6:38 AM
> To: Bernie Volz
> Cc: [email-masked]
> Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK
> 
> 
> 
> Thanks for pointing me to that draft.
> 
> I understand that the server does not keep track of (nor easily know)
> the client's state. It would be much clearer if message transmission
> (at least for the server) were described exclusively in the context of
> message type or in terms of the contents of the matching request.
> 
> However, message transmission includes reference to the client state.
> Those references are what I'm trying to clarify for myself.
> 
> I haven't attempted this, but I suppose if I were to map the client
> state to the request message contents, I may be able to describe
> server-side message transmission exclusvely in terms of 
> request contents.
> 
> Also, draft-ietf-dhc-implementation-01.txt doesn't appear to clarify
> delivery of the ACK. Can I safely assume that ACK's are 
> delivered based
> on the BROADCAST flag in all client states?
> 
> That wouldn't seem to be a good assumption since you should be able
> to deliver an ACK via unicast when you are renewing or rebinding (i.e.
> based on ciaddr being non-zero).
> 
> --kan--
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of
> > Bernie Volz
> > Sent: Sunday, 04 January, 2004 10:16 PM
> > To: 'Kevin A. Noll'
> > Cc: [email-masked]
> > Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK
> >
> >
> > See section 2.17 of
> > 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-implementation-01.txt.
> (Last three paragraphs of section 4.1 of RFC 2131 discuss the general case
> for server/relay to client communication.)
>
> Also, keep in mind that the client's state is not something that
> the server
> easily knows and it really doesn't need to.
>
> - Bernie
>

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Jan 2004 14:30:04 -0800

> reponse will be unicast back to that CIADDR.

Actually, this is not true for DHCPNAK, which indicates that the client 
is not correctly configured.   For DHCPNAK, the response has to be 
broadcast.   Which means that a DHCPNAK will never get to a client 
unless it is in INIT-REBOOT, SELECTING or REBINDING - that is, not when 
it is in RENEWING.   The one exception is that if the client is 
RENEWING, and is on the same network as the server, the DHCPNAK can get 
to the client.   But unless the server is looking at link-layer 
headers, it can't know that the client is on the local network anyway, 
so this doesn't matter very much in practice.   (See the bottom of page 
23 of RFC2131).