Subject: RE: [dhcwg] 'secs' field

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 1 Feb 2006 11:11:10 -0500

Ideally, the secs field represents the client's elapsed time since the
transaction was started. So, in the example you included, this means
that 6 seconds have elapsed between the messages.

However, you have to be careful because some clients actually send this
data incorrectly (ie, in host native byte ordering rather than in
network byte order) -- so, sometimes the values will be 0, 256, 512, ...
Instead of 0, 1, 2, .... (One not perfect fix for this is to always use
the lower value of this field represented in both network and host byte
order.)

In a long since expired draft on DHCPv4 implementation issues, Richard
Barr Hibbs and Rob Stevens wrote:

    2.22. Use of "secs" field 

        The "secs" field has not been discussed much:  many clients
simply 
        leave its value as zero, and few if any servers have used its
value 
        to modify their behavior. These practices seem acceptable.  The
value 
        of "secs" SHOULD be the elapsed time (in seconds) since the
client 
        began trying to acquire or extend a lease on an IP address.  A 
        sixteen bit field, its maximum value is 65536.  It is
conceivable 
        that due to server or network failure that a client may have
been 
        waiting longer than this. 

        RECOMMENDATIONS: 
            
        o  A client MAY choose to leave to ignore the secs field.  If so

           its value MUST be set to zero. If the client chooses to
insert 
           a value, the value SHOULD be time elapsed since the client 
           began negotiating for an IP address.  If the client has been 
           waiting longer than 65536 seconds its value SHOULD be 65536.

           The value SHOULD NOT wrap around to zero. 

Note that in DHCPv6, this same information is carried in the "Elapsed
Time Option".

One use of the "secs" field could be for a load balancing or "backup"
DHCP server -- that backup server might not service requests until the
elapsed time (secs) exceeds a threshold. See RFC 3074. Though I'm not
sure anyone has implemented this and as indicated above it could be
problematic for some clients that don't assure network byte order.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Michele Pedrolli
> Sent: Wednesday, February 01, 2006 10:55 AM
> To: [email-masked]
> Subject: [dhcwg] 'secs' field
> 
> The use of 'secs' field in the DHCP header isn't clear for me.
> 
>  From RFC 2131:
> - secs, filled by the client, seconds elapsed since client began  
> address acquisition or renewal process
> 
> and:
> 
> Field	DHCPOFFER	DHCPACK	DHCPNACK
> -------	-------------------	---------------	
> -----------------
> 'secs'	0				0		
> 	0
> 
> 
> So, in a RFC-compliant environment, all messagges coming from a DHCP  
> server MUST have 'secs' field set to 0. Is that right?
> I don't understand what expression "address acquisition" means.
> If a client send a DHCPDISCOVER and receives an OFFER, the following  
> DHCPREQUEST must have the secs field set with the number of seconds  
> elapsed from the first DHCPDISCOVER?
> 
> Analyzing a dhcp trace with Ethereal, I see duplicated DHCPACK  
> messages like this:
> 
> SRC			DST				TYPE	
> 	XID				SECS
> -----------------		-----------------------		
> ---------------	------------ 
> --------	---------
> 192.168.10.4	255.255.255.255 	DHCPACK 	
> 0xe7f6b0c 		0
> 192.168.10.4	255.255.255.255 	DHCPACK 	
> 0xe7f6b0c 		6
> 
> What's the meaning of the value 6 in the 2nd DHCPACK ?
> 
> 
> Although your previous messagges, I'm trying to find an 
> heuristic for  
> recognizing dhcp type messagges. I'll keep you in touch :-)
> 
> bye
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 1 Feb 2006 09:42:10 -0700

Actually, the secs field is theoretically useful in load balancing, since it 
provides you with a way to notice that a client is not getting serviced by 
the other server and step in.   So I disagree with Barr's wording in the last 
paragraph that you quoted.   It's wrong to say that clients can just set this 
field to zero all the time.   If that were not the case, why did we describe 
the Elapsed Time option in RFC3315?

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 1 Feb 2006 10:54:51 -0800

I'd like to add one more note to this;  All ISC DHCP Server versions 3.0
fill the 'secs' field with whatever the client packet that created the
need for a reply was filled with.  Wether it be OFFER, ACK, NAK, or
BOOTP, wether the client's packet be DISCOVER, REQUEST, or INFORM; the
behaviour is consistent in all cases.

> problematic for some clients that don't assure network byte order.

ISC DHCP has implemented this ("load balance max seconds [n];") in
its implementation of the failover draft, available in all 3.0.x
releases.

It does not really cause problems with clients that don't assure
network byte order.

Really, LBA is an optimization for failover.  The result of these
bogus large values is the nonoptimal OFFER by both servers - these
OFFER different addresses, and the number of clients that malform the
secs field are so small that it does not affect overall balance of
client activity between servers.

It might produce unexpected results, but these results are always safe,
normal operation, so we never hear complaint.

The real problem is clients that always fill the field with zero.

It is uncommon, but if one server is unable to hear or speak to a
client, but the other is fully capable, and the client continues to
advertise a zero value, it will never acheive an answer unless the
surviving server should move to communications-interrupted or
partner-down.

We do hear of this problem with fair frequency because people don't
realize "load balance max secs" relies upon the head field value.
They compare it to wall clock time and wonder why it failed.

Future implementations of ISC DHCP may try harder.  Using the 'xid'
field should be a reasonable approach, but I've already discovered
clients (albeit in INFORMs) that also fill the xid field with zeros.
It's not hard to imagine that it might be happening in DISCOVER/OFFER
with some regularity without our knowledge.

It should be noted with some amusement that this same implementation
that filled the xid value with zeroes also filled the ciaddr, htype,
hlen, and chaddr fields with zero.  On an INFORM.

Oh, and it failed to supply a client identifier option.

So, the logical conclusion is to create a hash of a "derived
client identity" (not for use in identifying the client for address
binding, rather uniquely for this purpose) from the first present value
of;

	1) The client identifier option contents, if exists.
	2) The chaddr field if hlen is nonzero.
	3) If giaddr is nonzero, the relay agent "remote id" option
		contents, if any.
	4) If giaddr is zero, the hardware source address of the packet.

Combine this id with the xid ("id:xid pair"), and hash a table of
timestamps when the client was last observed.  Periodically clean
the table of stale entries.

It should then be trivial to allow a sysadmin to configure "reply to
the client after the 3rd request or 5 'secs', whichever comes first"
with reasonable certainty that reqeusts from different clients won't
be confused.

-- 
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]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Robert Elz <[email-masked]>
Date: Thu, 02 Feb 2006 16:57:35 +0700

Date:        Wed, 1 Feb 2006 11:11:10 -0500
    From:        "Bernie Volz \(volz\)" <[email-masked]>
    Message-ID:  <[email-masked]>

This is kind of off topic, but should ...

  | In a long since expired draft on DHCPv4 implementation issues,

that draft ever get revived, it should probably explain ...

  |            If the client has been 
  |            waiting longer than 65536 seconds its value SHOULD be 65536.
  | 
  |            The value SHOULD NOT wrap around to zero. 

how the 16 bit field gets set to 65536 without wrapping around to zero?
What kind of magic encoding is being used here?   (Or perhaps just a very
heavy assignment statement that will force the value into a hole just
slightly too small without damaging it too much?)

(Or perhaps, change all uses of 65536 into 65535...)

kre

---

From: "Barr Hibbs" <[email-masked]>
Date: Sun, 1 Jan 2006 09:41:44 -0800

ooops!

good catch....

> From: Robert Elz
> Sent: Thursday, February 02, 2006 01:58
>