DHCP NAK Behavior

[Peter Kringle]

We have a DHCPREQUEST come into the DHCP server.  The server sends a DHCPNAK to the broadcast.  Because the device making the 
DHCPREQUEST is not on the same layer 2 network, the DHCPNAK never gets to the device.  The question is, which behavior is 
right?

Background information:
The DHCPREQUEST does NOT have a giaddr set
The request came in via unicast
The ciaddr is set
The 'server identifier' is not set
The 'requested IP address is not set

Reading RFC2131 we find 2 pieces of information that confict.

The section I am siding is.

      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
      the same subnet as the server.  The server MUST
      broadcast the DHCPNAK message to the 0xffffffff broadcast address
      because the client may not have a correct network address or subnet
      mask, and the client may not be answering ARP requests.
      Otherwise, the server MUST send the DHCPNAK message to the IP
      address of the BOOTP relay agent, as recorded in 'giaddr'.  The
      relay agent will, in turn, forward the message directly to the
      client's hardware address, so that the DHCPNAK can be delivered even
      if the client has moved to a new network.

The section my co-worker is siding with.

   o DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

      A client MAY choose to renew or extend its lease prior to T1.  The
      server may choose not to extend the lease (as a policy decision by
      the network administrator), but should return a DHCPACK message
      regardless.


-- 
Peter (K0VX)
http://www.planetnet.org