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


        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.


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
>       *           (
>        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.
>     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