DHCPNAK query

[David W. Hankins]

On Thu, Mar 18, 2010 at 08:49:29AM -0700, Friesen, Don SSBC:EX wrote:
>    Note that the NAK will not reach a remote client, the remote client 
> will continue to use the leased address until the lease expires and it 
> is forced to REBIND.  Since the address it has is a valid routable 

REBINDING (or "t2") is scheduled before lease expiration.  Basically
it is the client giving up on the server-identifier'd server, and
asking for any server to extend its lease before it expires.

It's true that the server's current strategy for NAK'ing RENEWING
clients is to send the DHCPNAK to the source interface at the all ones
limited broadcast, hoping it's a locally attached client (the server
cannot currently tell).  Remote clients won't get that, will reach
REBINDING, so get picked up by a relay agent which we can unicast our
DHCPNAK to, and the client gets it by broadcast there.


We don't answer RENEWING clients by unicast instead because I haven't
had the gumption to advance the issue at IETF DHC WG.

From RFC 2131 section 4.1 ("Constructing and sending DHCP messages");

   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.

"In all cases,"...not normative, but very clear.

The only normative language at all about this is in section 3.2
("Client-server interaction - reusing a previously allocated network
address");

      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.

Although that section is specific to basically the INIT-REBOOT
scenario when a client is reconnecting and broadcasting their
DHCPREQUESTs.

It's pretty clear the framers of 2131 intended DHCPNAK only for the
purpose of moving an un-configured client into a valid address, and
not for ACL/configuration/administrative purposes.  Despite that it's
very useful for same.  I say it's very clear because the RFC says as
much, pretty plainly;

   DHCPNAK      -  Server to client indicating client's notion of network
                   address is incorrect (e.g., client has moved to new
                   subnet) or client's lease as expired

The gist of this system is that once you give a client a valid lease,
you're making a promise the client can keep that lease for as long as
you've indicated.  In fact, although a proper client will renew and
then rebind before expiration, it can be said to be valid behaviour if
a client never contacted the server again and just waited out the
lease expiration.  It would be dumb, but permissible for that client
to use the lease the whole time until it expires.

So when migrating systems between address ranges, for example, it's
best to lower the lease-time sufficiently in advance of migration to
give the clients a smaller window to migrate.

Note that in 4.0.0, Christof Chen gave us a neat little patch that
gives clients an iteratively smaller lease-time the closer they
approach a "cut-over window", after which it refuses to give the lease
to any client from that range.  The client will expire out, DISCOVER,
get an OFFER from another range, and move on.  See the 'allow/deny
after [time];' configuration information in 'man dhcpd.conf'.


Still, it would be useful and quicker if the DHCP protocol allowed
NAK's on renewals.  Handy when you're in a tight spot and forgot to
lower the lease time in advance, or had no warning of the event.

So it's on my list.  It's a very long list tho.  Right now I'm trying
to get DHCPINFORM clarified so we can finally source lease information
when replying to Windows boxes doing DHCPINFORM's for WPAD - and give
them the right nameservers scoped with their pool, rather than
switching nameservers to some global config and breaking them.

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100318/da44a8f4/attachment.bin>