Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-04.txt

From: "David W. Hankins" <[email-masked]>
Date: Wed, 1 Nov 2006 14:55:08 +0000

On Tue, Oct 31, 2006 at 05:00:10PM +0530, Mukund Kamath wrote:
> * Why do we need this option?

I understand the first and foremost use case to be to allow a DHCP
server to reside outside of a private network (where there is no
routing between DHCP client and server).  DHCP as designed would
'succeed by failing' - clients would be unable to renew and would
enter the REBIND state, resulting in a broadcast carried by the
relay agent once again.

Note that since this has the neccessary effect of causing the DHCP
relay agent to become involved in clients in RENEW state, that
there are other situations - wherever 'snooping' DHCP packets in
relay agents has been used for example - where this streamlines and
formalizes other use cases.

> I feel that the relay agent can check all DHCP packets based on the UDP Destination port, and add the relay agent information. In such a case, this option would be redundant.

I do not think that would be appropriate behaviour for any device
on the network, much less a relay.

>       DHCP renew packets are unicast. Why do we need to send this packet to all the servers.

The alternative is to enter into state-keeping on the relay agent,
which is not very desirable.

It is better to give the servers the option to discard than to
introduce complexity in the relay agent.

> * The introduction ( paragraph 3 ) mentions that it would be easier for the relay agent to keep updated abt the  lease information etc. But on page 5, it is mentioned that the "intent is that relay agent need not have to maintain any lease information". I guess this conflict should be resolved. I personally feel that the relay agent should maintain the lease information, so that the information can be used to detect spoofing and prevent it as well.

'maintain lease informatin' means, to me, eg a stable storage device.

This draft does mention that a relay might make use of DHCP packet
contents on a per-client basis and that this is made easier.

However I would strongly advise against, and the draft makes no
requirement for, keeping state in stable storage on the relay.  It
can rebuild any running state from future DHCP packet exchanges since
it is involved in client RENEW state behaviour.

> * How is the RELEASE handled here? Is this unicast to the server or would it come to the RA ?

The client would unicast it to the server-identifier, which would be
set by the DHCP server to the value supplied by the override option.

Which is assumed to be 'a' relay agent, if not 'the' relay agent.

> If RA goes down, RELEASE will never reach the DHCP server and this can make the DHCP server hold the IP address until it timesout.

That is correct, which is also a risk to normal UDP packet loss.

> If it is unicast to the server, the packet might get routed over another path.

Unless, for example, there was no route between the client and
server anyway.

-- 
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: Ted Lemon <[email-masked]>
Date: Wed, 01 Nov 2006 11:21:18 -0700

> introduce complexity in the relay agent.

I'd just like to point out that by introducing this functionality in a 
failover environment, you are roughly doubling the load on each DHCP 
server.  So while I'm sympathetic to your argument that the relay agent 
shouldn't be maintaining state, there is a substantial cost involved.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 2 Nov 2006 16:01:42 +0000

> shouldn't be maintaining state, there is a substantial cost involved.

I think it is important to enter into state-keeping on the relay
where it is expressly necessary to meet an ends.

I'm growing more aware in the absence of alternative solutions I had
dreamed for this, there is going to need to be some state keeping on
relays to continue to afford failover implementations a 'load
balancing' incentive.

I also think it's important to make sure that if state keeping is
mandated for one purpose, it is not mandated for the general purpose.

That is, server-override should require no state keeping by the relay.

Failover support on a relay implementing server override might require
state keeping, no matter how much I wish it wouldn't.