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

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

A Client in the INIT-REBOOT state will not be filling in the CIADDR (RFC
2131, section 4.3.2).  Same as in the SELECTING state (the device has no
legitimate IP to put in the CIADDR).  For RENEWING, the request got to the
DHCP server (by unicast), so presumably (hopefully?) there's a proper route
back to the client.  So in those states, a unicast NAK will reach the
client.

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.

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, January 05, 2004 2:30 PM
> To: Kostur, Andre
> Cc: Bernie Volz; [email-masked]; 'Kevin A. Noll'
> Subject: Re: [dhcwg] Delivery of DHCPACK and DHCPNAK
> 
> 
> On Jan 5, 2004, at 11:43 AM, Kostur, Andre wrote:
> > Thus, if there is a valid CIADDR in the client's request, 
> the server's 
> > 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).
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Jan 2004 15:16:08 -0800

On Jan 5, 2004, at 3:04 PM, Kostur, Andre wrote:
> A Client in the INIT-REBOOT state will not be filling in the CIADDR 
> (RFC 2131, section 4.3.2).  Same as in the SELECTING state (the device 
> has no legitimate IP to put in the CIADDR).  For RENEWING, the request 
> got to the DHCP server (by unicast), so presumably (hopefully?) 
> there's a proper route back to the client.  So in those states, a 
> unicast NAK will reach the client.

No, because the DHCP server is sending the DHCPNAK to indicate that the 
client's configuration is incorrect.   So that means that routing back 
to the client won't work.   OTOH, routing from the client didn't work 
either, so probably the server never got that DHCPREQUEST.

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

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

---

From: "Steve Gonczi" <[email-masked]>
Date: Mon, 5 Jan 2004 19:41:57 -0500

Looks like Andre clearly said _if_ the request got to the server.

Given that the RENEW got to the server,
it may make sense to unicast a DHCPNAK.

I can imagine a scenario where the DHCPNAK is used merely
to enforce some policy (to revoke and otherwise workable
address)

>> unicast NAK will reach the client.

OTOH, Ted Lemon said....
>either, so probably the server never got that DHCPREQUEST.

Given that, probably no need to consider how a server
should handle a packet it did not receive.
:-)

Cheers

/sG

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Jan 2004 16:52:23 -0800

> to enforce some policy (to revoke and otherwise workable

This is not really something that's suggested by RFC2131.   DHCPNAK 
means the client is misconfigured for its network.   Unicasting a 
DHCPNAK back to the client sounds like a nice DoS attack to me, not 
that there aren't plenty of others in DHCP.

---

From: "Bernie Volz" <[email-masked]>
Date: Mon, 5 Jan 2004 21:49:20 -0500

In the most likely cases of interest, the DHCPREQUEST that the server is
NACKing will get to the server (see Table 4, below, copied from section
4.3.6 Client Messages of RFC 2131):

   ---------------------------------------------------------------------
   |              |INIT-REBOOT  |SELECTING    |RENEWING     |REBINDING |
   ---------------------------------------------------------------------
   |broad/unicast |broadcast    |broadcast    |unicast      |broadcast |
   |server-ip     |MUST NOT     |MUST         |MUST NOT     |MUST NOT  |
   |requested-ip  |MUST         |MUST         |MUST NOT     |MUST NOT  |
   |ciaddr        |zero         |zero         |IP address   |IP address|
   ---------------------------------------------------------------------

The INIT-REBOOT and REBINDING are broadcast by the client so the server will
receive them (either directly or from a relay). The RENEWING case is
unlikely to generate a DHCPNAK as a client probably hasn't move to a new
network - yes, there could be a renumbering event and in this case the
server might receive the message and could perhaps even send the DHCPNAK as
a unicast, but that's an edge case.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve
Gonczi
Sent: Monday, January 05, 2004 7:42 PM
To: [email-masked]
Subject: RE: [dhcwg] Delivery of DHCPACK and DHCPNAK

OTOH, Ted Lemon said....

Cheers

/sG