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

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 14 Feb 2003 11:53:27 -0800

> > If the device is in the REBINDING state, then the client is 
> > broadcasting it's REQUEST.  Since the Relay is down, the 
> DHCP Server 
> > still won't receive the Request, there's nothing to relay the 
> > broadcast to the server....
> 
> If you don't have a redundant network setup, you don't have a 
> redundant 
> network setup.   This is the same whether you are using the server 
> override option or not.   It's true that a site that has a redundant 
> router configuration but no redundant relay agent configuration would 
> be able to continue supporting renewals for existing clients 
> through a 
> relay agent outage, this isn't a very realistic scenario, and I don't 
> think it's a valid criticism of the draft.

OK, assuming that one has multiple relays on the network, then devices
at T2 will still be able to renew their leases (and new devices will
be able to acquire new leases).

In the redundant cases, does this imply that the redundant relays need
to pass whatever information it acquires from the DHCP clients to each
other through some other proprietary mechanism?  After the first set of
broadcasts used to establish a lease (which both relays will hear),
a DHCP client then only uses unicast packets to talk to one of the
relays.  The second relay will no longer hear from the client.  So after
the initial lease time expires, the second relay will "forget" about that
lease.  (It may even drop the lease once it sees the DHCPREQUEST pass
through that has a ServerID with a different IP than itself, although the
redundant relay could be configured to recognize the ServerID of it's
"partner" relay to prevent this.)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Feb 2003 14:25:46 -0600

> other through some other proprietary mechanism?

The point of this option is to ensure that the relays see every message 
from the client and therefore have an opportunity to insert a relay 
agent information option into each such message.   I don't know why it 
would be necessary for the relay agent to remember anything at all 
about the client, nor do I see any need for a proprietary or standard 
inter-relay-agent protocol.

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

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Feb 2003 16:24:34 +0700

Date:        Fri, 14 Feb 2003 14:25:46 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | The point of this option is to ensure that the relays see every message 
  | from the client and therefore have an opportunity to insert a relay 
  | agent information option into each such message.

I agree.

However, why is the server getting involved in this?   If the relay wants
its clients to see a DHCP SERVER option containing its IP address, why
wouldn't it just alter the reply back from the server to the client
(which goes back through the relay agent) ?

There should be no problem with later unicast renewals direct from client
to server, as the relay agent *is* the server as far as the client is
concerned.

kre

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Feb 2003 11:35:02 -0600

> (which goes back through the relay agent) ?

Because this would violate the DHCP authentication RFC - if you hack 
the middle of the packet, it breaks the security checksum.   If you 
make changes to the relay agent information option, as a relay agent, 
that's okay, because the DHCP client and server don't include that 
option when checking signatures.

This may seem academic right now, since nobody is using the DHCP 
authentication RFC, but I think that will change in the future, and the 
authors of this draft have rightly chosen not to create a new RFC 
that's in conflict with the old one.

---

From: Robert Elz <[email-masked]>
Date: Sun, 16 Feb 2003 13:16:56 +0700

Date:        Sat, 15 Feb 2003 11:35:02 -0600
    From:        Ted Lemon <[email-masked]>
    Message-ID:  <[email-masked]>

  | Because this would violate the DHCP authentication RFC

OK, that makes sense.

kre