The DHCPNAK is sent by the windows DHCP server configured but my device with ISC dhcp-4.1.0 is unable to send the DHCPNAK.<br>Plz suggest if this is the expected behaviour or not.<br><br>-kalyan <br><br><div class="gmail_quote">
On Fri, Mar 19, 2010 at 3:20 PM, kalyan Alle <span dir="ltr"><<a href="mailto:kalyan.alle@gmail.com">kalyan.alle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have got the issue with the setup as below<br><br><pre> <b>          (169.254.128.132)<br>  1) DUT(SU)(DHCP Server)----Ethernet0-----Win XP PC (DHCP Client)<br><br>  2) Windows 2003 Server (192.168.9.2) ----Eth----WIN XP (DHCP Client)</b></pre>

<b><br></b><pre><b>4) Enable the DHCP Server on DUT<br>5) Make WinXP PC as Client and get the ip address (say 169.254.128.10)<br>6) Disconnect the DHCP Client PC and connect to windows 2003 Server i.e another<br>
DHCP Server configured on 192.168.9.0 subnet. <br>7) DHCP Client sends the DHCP request message with the old ip address, DHCP<br>server ( windows 2003 server) responds with DHCPNAK message and after receiving<br>DHCPNAK the client restarts the allocation procedure with DHCPDISCOVER message.<br>

8) Clients gets ip address from Win server as 192.168.9.100.<br>9) Disconnect the DHCP Client and reconnect to Mumbai SU/DUT.<br>10)Again DHCP client sends the DHCP request message to the DHCP server with<br>assigned ip address which is in 192.168.9.0 subnet to DUT DHCP server.<br>

The DUT DHCP server is silent and doesn't send any DHCPNAK message.<br><br>Can any one comment or let me know the solution for this scenario.<br><br>thanks<br>kalyan</b><br></pre><div><div></div><div class="h5"><br><br>
<br><br><div class="gmail_quote">
On Fri, Mar 19, 2010 at 12:40 PM, kalyan Alle <span dir="ltr"><<a href="mailto:kalyan.alle@gmail.com" target="_blank">kalyan.alle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Thank you guys for letting me know this is not a bug. It works as designed.<br><font color="#888888"><br><br>-kalyan<br><br></font><div class="gmail_quote"><div><div></div><div>On Fri, Mar 19, 2010 at 4:50 AM, David W. Hankins <span dir="ltr"><<a href="mailto:dhankins@isc.org" target="_blank">dhankins@isc.org</a>></span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div><div>On Thu, Mar 18, 2010 at 08:49:29AM -0700, Friesen, Don SSBC:EX wrote:<br>


>    Note that the NAK will not reach a remote client, the remote client<br>
> will continue to use the leased address until the lease expires and it<br>
> is forced to REBIND.  Since the address it has is a valid routable<br>
<br>
</div>REBINDING (or "t2") is scheduled before lease expiration.  Basically<br>
it is the client giving up on the server-identifier'd server, and<br>
asking for any server to extend its lease before it expires.<br>
<br>
It's true that the server's current strategy for NAK'ing RENEWING<br>
clients is to send the DHCPNAK to the source interface at the all ones<br>
limited broadcast, hoping it's a locally attached client (the server<br>
cannot currently tell).  Remote clients won't get that, will reach<br>
REBINDING, so get picked up by a relay agent which we can unicast our<br>
DHCPNAK to, and the client gets it by broadcast there.<br>
<br>
<br>
We don't answer RENEWING clients by unicast instead because I haven't<br>
had the gumption to advance the issue at IETF DHC WG.<br>
<br>
>From RFC 2131 section 4.1 ("Constructing and sending DHCP messages");<br>
<br>
   If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is<br>
   set, then the server broadcasts DHCPOFFER and DHCPACK messages to<br>
   0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and<br>
   'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK<br>
   messages to the client's hardware address and 'yiaddr' address.  In<br>
   all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK<br>
   messages to 0xffffffff.<br>
<br>
"In all cases,"...not normative, but very clear.<br>
<br>
The only normative language at all about this is in section 3.2<br>
("Client-server interaction - reusing a previously allocated network<br>
address");<br>
<br>
      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on<br>
      the same subnet as the server.  The server MUST<br>
      broadcast the DHCPNAK message to the 0xffffffff broadcast address<br>
      because the client may not have a correct network address or subnet<br>
      mask, and the client may not be answering ARP requests.<br>
<br>
Although that section is specific to basically the INIT-REBOOT<br>
scenario when a client is reconnecting and broadcasting their<br>
DHCPREQUESTs.<br>
<br>
It's pretty clear the framers of 2131 intended DHCPNAK only for the<br>
purpose of moving an un-configured client into a valid address, and<br>
not for ACL/configuration/administrative purposes.  Despite that it's<br>
very useful for same.  I say it's very clear because the RFC says as<br>
much, pretty plainly;<br>
<br>
   DHCPNAK      -  Server to client indicating client's notion of network<br>
                   address is incorrect (e.g., client has moved to new<br>
                   subnet) or client's lease as expired<br>
<br>
The gist of this system is that once you give a client a valid lease,<br>
you're making a promise the client can keep that lease for as long as<br>
you've indicated.  In fact, although a proper client will renew and<br>
then rebind before expiration, it can be said to be valid behaviour if<br>
a client never contacted the server again and just waited out the<br>
lease expiration.  It would be dumb, but permissible for that client<br>
to use the lease the whole time until it expires.<br>
<br>
So when migrating systems between address ranges, for example, it's<br>
best to lower the lease-time sufficiently in advance of migration to<br>
give the clients a smaller window to migrate.<br>
<br>
Note that in 4.0.0, Christof Chen gave us a neat little patch that<br>
gives clients an iteratively smaller lease-time the closer they<br>
approach a "cut-over window", after which it refuses to give the lease<br>
to any client from that range.  The client will expire out, DISCOVER,<br>
get an OFFER from another range, and move on.  See the 'allow/deny<br>
after [time];' configuration information in 'man dhcpd.conf'.<br>
<br>
<br>
Still, it would be useful and quicker if the DHCP protocol allowed<br>
NAK's on renewals.  Handy when you're in a tight spot and forgot to<br>
lower the lease time in advance, or had no warning of the event.<br>
<br>
So it's on my list.  It's a very long list tho.  Right now I'm trying<br>
to get DHCPINFORM clarified so we can finally source lease information<br>
when replying to Windows boxes doing DHCPINFORM's for WPAD - and give<br>
them the right nameservers scoped with their pool, rather than<br>
switching nameservers to some global config and breaking them.<br>
<font color="#888888"><br>
--<br>
David W. Hankins        BIND 10 needs more DHCP voices.<br>
Software Engineer               There just aren't enough in our heads.<br>
Internet Systems Consortium, Inc.               <a href="http://bind10.isc.org/" target="_blank">http://bind10.isc.org/</a><br>
</font><br></div></div><div>_______________________________________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org" target="_blank">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br></div></blockquote></div><br>
</blockquote></div><br>
</div></div></blockquote></div><br>