Subject: [dhcwg] RFC 2131,Question regarding DHCPNAKs

From: [email-masked]
Date: Wed, 20 Feb 2008 16:03:40 -0500

Hello,

I need clarification on RFC 2131.  In my network, DHCP clients are two 
routed hops away from my DHCP servers.  The first routed hop acts as a 
relay agent.  I hope the following diagram remains intact through email.

______
|   S-1   |__________
|             |                       |
-----------            _____|______ ____________ ______________  
__________                       ________   
                          |       L2              |    |         |     | 
Router 1            |                |    L2              |       |   DHCP 
  |
                          |    Switch         |--------------------| 
Router 2       |---------------|       and                 |------------|  
Switch       |----------------|   Client     |
                          -------------------- | |                    | 
Relay Agent    |                ------------------ ---------------
______                        | --------------------- 
-------------------------
|   S2     |                       |
|             |------------------
-----------

At T1 the client has a lease and unicasts its request to the server that 
issued its lease.  It set the flag field to 0, indicating a unicast.  The 
request packet is simply routed through both routers that reside between 
the client and the DHCP servers.  For administrative purposes the server 
has been configured to not renew any existing leases, so, responds with a 
DHCPNAK.  However, the server broadcasts this NAK, and leaves the flag 
field set to 0.  The broadcasted NAK doesn't get past the first router in 
the path (Router 2 in the diagram), so never even gets to the relay agent. 
 The client doesn't receive the NAK, so, getting no response at all to its 
renew request, continues to use the lease until T2.

At T2 the client broadcasts its renew request, the relay agent does its 
job, and the servers' NAK makes it back to the client.  The problem is, 
the server upon broadcasting the NAK at T1, reclaimed the lease, while the 
client was still using it.

The question is, when a client at T1 unicasts its renew request to the 
server, shouldn't the server unicast the NAK back.  I've read over the RFC 
a few times now, and I find what appears to be conflicting information.

For instance, the last sentence in para 5, section 4.1:

 "In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK 
messages to 0xffffffff."

 This line seems very clear, until read later in the same section:

Normally, DHCP servers and BOOTP relay agents attempt to deliver
   DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
   unicast delivery.  The IP destination address (in the IP header) is
   set to the DHCP 'yiaddr' address and the link-layer destination
   address is set to the DHCP 'chaddr' address.  Unfortunately, some
   client implementations are unable to receive such unicast IP
   datagrams until the implementation has been configured with a valid
   IP address (leading to a deadlock in which the client's IP address
   cannot be delivered until the client has been configured with an IP
   address).

   A client that cannot receive unicast IP datagrams until its protocol
   software has been configured with an IP address SHOULD set the
   BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
   DHCPREQUEST messages that client sends.  The BROADCAST bit will
   provide a hint to the DHCP server and BOOTP relay agent to broadcast
   any messages to the client on the client's subnet.  A client that can
   receive unicast IP datagrams before its protocol software has been
   configured SHOULD clear the BROADCAST bit to 0.  The BOOTP
   clarifications document discusses the ramifications of the use of the
   BROADCAST bit [21].

   A server or relay agent sending or relaying a DHCP message directly
   to a DHCP client (i.e., not to a relay agent specified in the
   'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
   field.  If this bit is set to 1, the DHCP message SHOULD be sent as
   an IP broadcast using an IP broadcast address (preferably 0xffffffff)
   as the IP destination address and the link-layer broadcast address as
   the link-layer destination address.  If the BROADCAST bit is cleared
   to 0, the message SHOULD be sent as an IP unicast to the IP address
   specified in the 'yiaddr' field and the link-layer address specified
   in the 'chaddr' field.  If unicasting is not possible, the message
   MAY be sent as an IP broadcast using an IP broadcast address
   (preferably 0xffffffff) as the IP destination address and the link-
   layer broadcast address as the link-layer destination address.

and from section 4.3.2:

DHCPREQUEST generated during RENEWING state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST NOT be filled in, 'ciaddr' MUST be filled in with
      client's IP address. In this situation, the client is completely
      configured, and is trying to extend its lease. This message will
      be unicast, so no relay agents will be involved in its
      transmission.  Because 'giaddr' is therefore not filled in, the
      DHCP server will trust the value in 'ciaddr', and use it when
      replying to the client.

After reading over this several times, the way I interpret the RFC is that 
the server should honor the flag field, If the flag field is set to 
unicast, the server should unicast the NAK to the client using either the 
yiaddr or the ciaddr (not sure which).

Please supply guidance on how the DHCP server should behave in this 
scenario.

Thanks very much for your time and attention.

Jeff Holmes
Sr. Network Engineer
Verizon
703-375-4737

_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 22 Feb 2008 12:02:49 -0800

> relay agent.  I hope the following diagram remains intact through email.

It didn't, but I think I get the picture.

You've got a relay.

> field set to 0.

This is a practice that is not encoded in RFC2131.  It's sort of an
operational thing.  It's true that many clients will respond as you
might expect to a NAK in RENEWING state.  It cannot be relied upon
in RFC2131 conforming implementations since it is not specified.

At the same time it is never said explicitly that a server is not
allowed to send such a message.

> client was still using it.

It is a bad assumption to revoke a lease in this case.  The client is
under no obligation to conform to the NAK - particularly as you have
found out the ones they don't receive.

Revoking the lease at T2 when the client REBINDs is a bit less insane,
but is still inadvisable.  It would be most advisable to retain the
lease until the lease expires.

> a few times now, and I find what appears to be conflicting information.

Ah, now that's a good question.

I can't speak to the specific quotes from 2131 you've supplied, but I
can tell you what I learned the last time I went down this rabbit
hole.

That DHCPNAK must always be transmitted to broadcast is
incontrovertible, unless you accept that RFC 2131 is only making that
claim to the extent that it claims DHCPNAK is used; in INIT-REBOOT,
BINDING, and REBININDG clients to direct them to the appropriate
network.  I am not free to make such an exclusion, but we are talking
about interpreting smoke here.

There is also no RFC2131 text that directs a server to reply to
RENEWING clients with a DHCPNAK.  So if you do so, the behaviour
cannot be said to be RFC2131 compliant.  It also cannot be said to
be RFC2131 incompliant.

So one safe interpretation (the one ISC DHCP hopefully implements) is
to refuse to DHCPNAK a RENEWING client, or even to respond at all.
The client will ultimately reach T2 and begin REBINDING, at which
point it may be NAKed in compliance with both RFC2131 and the
operator's will.

In ISC DHCP's case, the old lease is never revoked unless it expires
on its own -or- the client, having precisely the same identifier,
binds to a different address (REQUEST/ACK succeeds on a different
address).  This last bit is something I have found in our own sources
and have frequently questioned its compliance, but I thought I would
mention it for completeness.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/dhcwg

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 22 Feb 2008 15:30:04 -0500

At 03:02 PM 2/22/2008, David W. Hankins wrote:
>[...]

        Except for the state transition diagram, Figure 5, on
        page 35 of RFC 2131.  Which shows what a client is to do
        when receiving a DHCPNAK when it is renewing.  There is,
        I agree, no text that discusses this behavior.

>lease until the lease expires.

        That seems overly conservative to me.  If you retain
        the lease until you are sure the client is in the INIT
        state -- that is, until you receive a DHCPDISCOVER from
        the client -- you should be fine.

        Regards -- Kim

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 22 Feb 2008 14:18:58 -0800

>         I agree, no text that discusses this behavior.

Yes, that's right.  I know that many perceive the state diagram as
normative, but I observe it largely as an implementation aid following
from the text below it.  The 1.4 Requirements section in particular
does not describe "a dashed line" as "REQUIRED", only the keyword
"MUST" is given that definition.

>         the client -- you should be fine.

Perhaps so, but anecdotally I'm aware of clients that often DISCOVER
when they are still in fact BOUND (for whome an ICMP echo request
of a next-to-be OFFERed address succeeds because the client is still
using it).  So revoking a lease on DISCOVER presumes that the OFFER
will succeed in reaching the client, and that a subsequent REQUEST/ACK
will reconfigure the client.  I may not like this behaviour (I would
have preferred it to be a REQUEST mimicking any of REBIND,
INIT-REBOOT, or RENEW), but I can't change other people's software.

So perhaps I prefer a slightly more conservative view.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 22 Feb 2008 14:27:50 -0800

> So perhaps I prefer a slightly more conservative view.

Let me be clearer; I agree that revoking the lease on DISCOVER is at
least less insane than revoking the lease upon detecting the client
is REBINDING, but also believe that I have tangible technical reasons
for preferring even more caution.