may server send NAK to client that is REBINDING or RENEWING?

[Irwin Tillman <[e-mail]>]

May the server ever send a DHCKNAK to a DHCPREQUEST, if the client
is in RENEWING or REBINDING state?

I'm having trouble deciding this based on draft-ietf-dhc-dhcp-07.txt:

Section 4.3.2 describes how the server handles DHCPREQUESTS; these
two states are covered in the last two bulleted items, but are not
entirely clear as to whether DHCPNAKs are ever sent in these states.
  
The state transition diagram for clients in Figure 5 appears to show
that the client may receive DHCPNAK when in RENEWING or REBINDING states.

Section 4.4.5 describes how the client does lease reacquisition
and expiration; it describes what the client does when it
gets a DHCPACK or no response to a DHCPREQUEST sent in either state,
but not what it does if it gets a DHCPNAK in either state.

--------------

Here's my reading of the scenarios:

Section 4.3.2 describes the server's handling of DHCPREQUEST.
The bulleted item "DHCPREQUEST generated during RENEWING state" does not
describe what checks, if any, the server must or may perform
before responding to the client.  

It does say "Becayse 'giaddr' is therefore not filled in, the DHCP
server will trust the value in 'ciaddr', and use it when replying
to the client."  (OK, so the server can not determine whether
the ciaddr is appropriate for the client's present IP-subnet;
it should not base any decision on that at this point.)

It does say that "The server may choose not to extend the lease (as a policy
decision by the network administrator), but should return a DHCPACK
message regardless."

But what if the server unequivocally knows that the lease is
not valid?  Does the statement above mean that the server
should still return a DHCPACK?  May it return a DHCPNAK?
Or must it be silent?

The server knows the client is in the RENEWING state
(DHCPREQUEST received does not contain server identifier option,
does not contain requested IP address option, giaddr == 0, and
destIP==server's IP address).  Given that this packet must have
been unicast by the client to us, the client must believe
the lease is one that this particular server granted, right?

So I would think the server should look for ciaddr in its table of
unexpired leases, and if it is not found, unicast a DHCPNAK to ciaddr.

And then, if the request passes that check, the
server may compare any client identifier in the DHCPREQUEST
with the client identifier in the unexpired lease, and if they
do not match, unicast a DHCPNAK to ciaddr.

----

In the same section (4.3.2), the bulleted item "DHCPREQUEST generated
during REBINDING state" does say "The DHCP server SHOULD check
'ciaddr' for correctness before replying to the DHCPREQUEST."

It does not describe what should be considered "correct", nor
does it say whether the server should send a DHCPNAK or
be silent if the 'ciaddr' is not considered correct.

The server can compare ciaddr with giaddr and its
knowledge of the network topology, and if it *knows*
that ciaddr is on the wrong IP-subnet, can send a DHCPNAK.
(If it is not sure, it should not send the DHCPNAK.)

But there are other tests of correctness that appear to
be possible...

The server knows that the client is in the REBINDING state
(DHCPREQUEST received does not contain server identifier option,
does not contain requested IP address option, and either
the giaddr is nonzero, or the dstIP is broadcast).  So the
server can't be sure whether the lease the client is renewing
was one that this particular server granted.

Given that, the server can lookup ciaddr in its table
of unexpired leases.  If found, it may compare any
client identifier in the DHCPREQUEST with the client identifier
in the unexpired lease, and if they do not match,
send a DHCPNAK.  Otherwise, send a DHCPACK.

Otherwise, if the ciaddr is not in the table of unexpired leases,
the server can look for ciaddr in any other tables of
ip addresses for which it knows it has authority,
and if found, send a DHCPNAK.  (I.e. the server knows it
is authoratitive for leases involving this IP address,
and it knows there is not any lease presently for this
IP address.)  

Otherwise, be silent.

---------







-- 

Irwin Tillman, [e-mail]
CIT Network Systems, Princeton University