DHCPNAK query
Glenn Satchell
glenn.satchell at uniq.com.au
Fri Mar 19 10:10:04 UTC 2010
Have you included the authoritative statement? by default ISC dhcpd is
not authoritative. See dhcpd.conf man page, following on from the
earlier section already posted:
...
If the server knows nothing about the address,
it will remain silent, unless the address is incorrect for
the network segment to which the client has been attached
and the server is authoritative for that network segment, in
which case the server will send a DHCPNAK even though it
doesn't know about the address.
...
The authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configura-
tion information about a given network segment is not
known to be correct and is not authoritative. This is so
that if a naive user installs a DHCP server not fully
understanding how to configure it, it does not send spuri-
ous DHCPNAK messages to clients that have obtained
addresses from a legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP
servers for their networks should always write authorita-
tive; at the top of their configuration file to indicate
that the DHCP server should send DHCPNAK messages to mis-
configured clients. If this is not done, clients will be
unable to get a correct IP address after changing subnets
until their old lease has expired, which could take quite
a long time.
regards,
-glenn
On 03/19/10 21:00, kalyan Alle wrote:
> 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
> <mailto: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
> <mailto: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 <mailto: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/
>
More information about the dhcp-users
mailing list