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

From: "Kostur, Andre" <[email-masked]>
Date: Mon, 5 Jan 2004 15:27:00 -0800

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, January 05, 2004 3:16 PM
> To: Kostur, Andre
> Cc: Bernie Volz; [email-masked]; 'Kevin A. Noll'; 'Ted Lemon'
> Subject: Re: [dhcwg] Delivery of DHCPACK and DHCPNAK
> 
> > REBINDING may be a different case in that the client is 
> broadcasting 
> > the request to begin with, thus may not be coming from the correct 
> > network, so a broadcast NAK reponse to a REBIND makes sense 
> (basically 
> > the same reasons as the INIT-REBOOT case).  In this case I 
> can see a 
> > clarification for 2131 to describe a proper NAK response in 
> this case.
> 
> RFC2131 is quite explicit in saying that you have to 
> broadcast DHCPNAK 
> when giaddr is zero, and you have to send the response to 
> giaddr if it 
> is nonzero.   What rfc2131 is lamentably unspecific about is 
> when it's 
> appropriate to send a DHCPNAK.

Whups.... you're right.  Heck, it's even in the paragraph that _I_ quoted
from 2131: "In all cases, when 'giaddr' is zero, the server broadcasts any
DHCPNAK messages to 0xffffffff.".

Although, interestingly, the top of page 25 says "Normally, DHCP servers and
BOOTP relay agents attempt to deliver   DHCPOFFER, DHCPACK and DHCPNAK
messages directly to the client using uicast delivery." (OK, that probably
should be "unicast"...)