DHCPNAK query
kalyan Alle
kalyan.alle at gmail.com
Fri Mar 19 10:00:52 UTC 2010
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.
Plz suggest if this is the expected behaviour or not.
-kalyan
On Fri, Mar 19, 2010 at 3:20 PM, kalyan Alle <kalyan.alle at gmail.com> wrote:
> I have got the issue with the setup as below
>
> * (169.254.128.132)
> 1) DUT(SU)(DHCP Server)----Ethernet0-----Win XP PC (DHCP Client)
>
> 2) Windows 2003 Server (192.168.9.2) ----Eth----WIN XP (DHCP Client)*
>
> *
> *
>
> *4) Enable the DHCP Server on DUT
> 5) Make WinXP PC as Client and get the ip address (say 169.254.128.10)
> 6) Disconnect the DHCP Client PC and connect to windows 2003 Server i.e another
>
> DHCP Server configured on 192.168.9.0 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 192.168.9.100.
> 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 192.168.9.0 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.
>
> thanks
> kalyan*
>
>
>
>
>
> 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
>>> 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/
>>>
>>> _______________________________________________
>>> 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/aadcdd11/attachment.html>
More information about the dhcp-users
mailing list