kalyan.alle at gmail.com
Fri Mar 19 07:10:43 UTC 2010
Thank you guys for letting me know this is not a bug. It works as designed.
On Fri, Mar 19, 2010 at 4:50 AM, David W. Hankins <dhankins at isc.org> wrote:
> 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
> 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
> 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/
> dhcp-users mailing list
> dhcp-users at lists.isc.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users