kalyan Alle kalyan.alle at gmail.com
Fri Mar 19 09:50:23 UTC 2010

I have got the issue with the setup as below

 *          (
  1) DUT(SU)(DHCP Server)----Ethernet0-----Win XP PC (DHCP Client)

  2) Windows 2003 Server ( ----Eth----WIN XP (DHCP Client)*


*4) Enable the DHCP Server on DUT
5) Make WinXP PC as Client and get the ip address (say
6) Disconnect the DHCP Client PC and connect to windows 2003 Server i.e another
DHCP Server configured on subnet.
7) DHCP Client sends the DHCP request message with the old ip address, DHCP
server ( windows 2003 server) responds with DHCPNAK message and after receiving
DHCPNAK the client restarts the allocation procedure with DHCPDISCOVER message.
8) Clients gets ip address from Win server as
9) Disconnect the DHCP Client and reconnect to Mumbai SU/DUT.
10)Again DHCP client sends the DHCP request message to the DHCP server with
assigned ip address which is in subnet to DUT DHCP server.
The DUT DHCP server is silent and doesn't send any DHCPNAK message.

Can any one comment or let me know the solution for this scenario.


On Fri, Mar 19, 2010 at 12:40 PM, kalyan Alle <kalyan.alle at gmail.com> wrote:

> Thank you guys for letting me know this is not a bug. It works as designed.
> -kalyan
> 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
>> 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
>> 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
>> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100319/6db2b502/attachment.html>

More information about the dhcp-users mailing list