Subject: RE: RFC 2131 clarification (fwd)

From: harshavj <[email-masked]>
Date: Fri, 19 Feb 1999 05:10:53 -0500 (EST)

Hi shashi,

There is a criteria for bootp relay agents to give higher priority to the   
pkts which have higher 'sec's value; assuming that they were waiting for   
a long time. But I hope there is no mapping and data maintained by relay   
agents which contained mapping of secs and some client info (xids/Client   
ID) to a particular server/s. I have not used such a mapping for our   
inhouse Dhcp Relay agent after confirming that this was not needed. I   
have raised a similar question before dealing this issue on this list   
sometime back.
I would appreciate if some one point out that this is required.

You can go through RFC 1542 which gives some clarifications on these   
issues. But Ted says this RFC is absolate. I am not sure whether this   
behaviour was retained in the latest RFC. Here is a draft which addresses   
some of your needs.

http://search.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-04.txt  

But a Dynamic database containing some client info (such as CIient   
identifier & Xid) to Server inside will definitly help the relay agent to   
simply send the H/W unicast to the particular client in return path from   
Server. This will also help the Relay agents to quickly fwd the   
BOOTPREQUESTS and OFFERS before the Client will timeout. I appreciate   
your comments.

Thanks & Regards,

Harsha
 --------------------------------------------------------------------------  
 --------------------------------------------------------
Future Software Pvt Ltd.,
481, Mt Road,
Nandanam,
Mt Road,
Chennai
INDIA
 --------------------------------------------------------------------------  
 --------------------------------------------------------

 -----Original Message-----
From: [email-masked] [SMTP:[email-masked]]
Sent: Friday, February 19, 1999 3:11 AM
To: [email-masked]
Subject: RFC 2131 clarification (fwd)

    *** From dhcp-client -- To unsubscribe, see the end of this message.   
***

 ---------- Forwarded message ----------
Date: Thu, 18 Feb 1999 15:33:55 -0600 (CST)
From: [email-masked]
To: [email-masked]
Subject: RFC 2131 clarification

Hi
In the RFC 2131 under section 3 Client-Server Protocol Page 15 item 3

"To help
     ensure that any BOOTP relay agents forward the DHCPREQUEST message
     to the same set of DHCP servers that received the original
     DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
     value in the DHCP message header's 'secs' field and be sent to the
     same IP broadcast address as the original DHCPDISCOVER message.
     The client times out and retransmits the DHCPDISCOVER message if
     the client receives no DHCPOFFER messages."

Why should the 'secs' field be the same, what purpose this serve ?

Can anyone please explain

cheers
shashi

 --------------------------------------------------------------------------  
 ----
To unsubscribe from this list, please visit   
http://www.fugue.com/dhcp/lists
If you are without web access, or if you are having trouble with the web   
page,
please send mail to [email-masked].   Please try to use the web
page first - it will take a long time for your request to be processed by   
hand.
 --------------------------------------------------------------------------  
 ----

---

From: Ralph Droms <[email-masked]>
Date: Sat, 20 Feb 1999 23:04:32 -0500 (EST)

>Can anyone please explain

In general, this text was included to guarantee that the REQUEST message
would reach and be processed by the server from which the selected OFFER
was received.  In particular, when we wrote the original DHCP spec, there
were BOOTP relay agents that would perform load balancing by forwarding
DHCP messages to different servers based, in part, on the value of the
'secs' field. There was no state kept for each message; rather, there was
an algorithm in the relay agent that would compute the destination based on
the contents of the message to be forwaarded.  So, the specific text was
added to ensure that the contents of the REQUEST message would cause it to
be forwarded to the same server or servers as the original DISCOVER
message, which would include the server from which the selected OFFER was
received.

Servers may also filter messages based on the 'secs field, as Philip
Guenther pointed out:

>Some servers and gateways can be configured to not respond to request
>packets with a secs field below a given value.  This allows for the
>easy implementation of fall-back servers and 'expanding ring' style
>searches.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sun, 21 Feb 1999 13:09:03 -0500 (EST)

Hm.  The current ISC DHCP client doesn't implement the behaviour as
specified, and it looked like about five minute's work to implement
it, so just now I tried.  While I was doing so, it occurred to me that
we don't actually have a way to match DHCPDISCOVER and DHCPOFFER
messages precisely - we don't know that a particular offer was a
response to a particular discover, if we've been retransmitting.  So
if we use, e.g., the secs value from the last DHCPDISCOVER we sent,
this might be *different* than the secs value that got us the
DHCPOFFER we chose.

The only way to reliably make sure we use the secs value that got us a
particular offer is to have the server send the secs value from the
client's DHCPDISCOVER back in the secs field of its DHCPOFFER.
Unfortunately, rfc2131 says quite unequivocally that the server is
always supposed to send back a secs value of zero.

IMHO, this breaks the functionality that you are describing pretty
badly - it's not at all uncommon in my experience, because of the Echo
Request and the fast timeout on Microsoft clients, for the first
DHCPOFFER a Microsoft client receives to be the response to its first
DHCPDISCOVER, even though it's subsequently *sent* a second
DHCPDISCOVER.   I've even seen this happen with a slow server and the
ISC client at times, even though the ISC client has a much slower
initial timeout.

So how do we fix this?   I'd suggest that we either give up on having
this feature in the current protocol, that is, take out the section
that says the secs field in the DHCPREQUEST has to be the same as the
secs field in the DHCPDISCOVER, or specify different behaviour and
accept that it will not initially be widely implemented.

My suggestion is that we take out the current language and put it back
in the DHCPv4ng protocol specification, whenever that happens, with
the following changes:

	 - when the server generates a DHCPOFFER, it sets secs to the
	   value it found in the DHCPDISCOVER packet.
	 - When the client sends a DHCPREQUEST in response to a
	   DHCPOFFER, it uses the secs field from the DHCPOFFER, NOT
	   the secs field from its most recent DHCPDISCOVER.

For now, my plan is to not implement the behaviour specified in
rfc2131 - I unfortunately can't see any way to make it work.  Is
anybody currently using (as opposed to implementing) the behaviour
currently specified in rfc2131?

			       _MelloN_