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

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 14 Feb 2003 09:07:10 -0800

A few observations:

1) This introduces a new point of failure in a DHCP infrastructure.  If this
particular relay goes down, then devices which currently hold a lease cannot
renew, where under standard DHCP, they would be able to.

2) It also seems kinda odd that the DHCP Server should only sometimes pay
attention to this sub-option:

   DHCP Servers SHOULD use this value as the value to insert into the
   Server-ID option ONLY when the protocol is in the SELECTING and
   REQUESTING and REBINDING states.  If this suboption appears in a DHCP
   request which is part of a lease RENEWAL, it SHOULD be ignored.

What's the justification of the server ignoring the value for RENEWALs?
This would mean that a client Renewing their lease (T1 expiries) will get a
response from a DHCP sever that it didn't unicast a Request to.  Details:

SvrIP = DHCP Server IP
RelayIP = Relay IP

- Client broadcasts a Discover
- Relay receives Discover, does the normal relay duties, and adds Opt82 with
the RelayIP as the override
- Server processes Discover and sends back an Offer with a SeverID of
RelayIP (according to this draft).
- Relay receives Offer, does the normal relay duties, and broadcasts back to
the client.
- Client receives the Offer, and records RelayIP as the server which is
servicing this client.
- Client broadcasts a Request, with ServerID of RelayIP 
- Relay receives the Request, does the normal relay duties, and adds Opt82
with the RelayIP as the override
- Server receives the Request.  Since the ServerID is not the DHCP Server's
IP, the Request is ignored!

Actually there's another problem... the DHCP Server will ignore the Request!
But let's continue, assuming that this is accepted somehow by the server:

- Server sends back an Ack with a ServerID of RelayIP
- Time passes until T1
- Client unicasts a Request to RelayIP
- Relay receives Request, does the normal relay duties, and adds Opt82 with
the RelayIP as the override
- Server receives the Request, and Acks with a ServerID of SvrIP (according
to this draft, the RENEWAL should ignore the override)
- Relay receives the ACK, does the normal relay duties, unicasts it back to
the client
- The Client receives an ACK from what appears to be a completely different
DHCP Server!

2 things may happen at this point.  The first is that the client might
decide to discard the answer since it didn't come from the DHCP Server that
it sent the request to, or the client may change which DHCP Server it's
going to try talking to since it now has an answer from the actual server.
Assuming the second case happens, when the client tries to renew the next
time, it will try to unicast directly to the DHCP server, and will bypass
the relay altogether, defeating the purpose of this draft!

On a side (but somewhat related) note, I think I've found a discrepancy
between RFC 2131 and RFC 2132 with respect to the Server ID option.

In RFC 2131, Section 4.3.1, Page 29, Table 3:  This table indicates that a
server MUST include the Server ID option in Offers, Acks, and Nacks.

In RFC 2132, Section 9.7, Page 27: The description of the Server ID option
states that "This option is used in DHCPOFFER and DHCPREQUEST messages, and
may optionally be included in the DHCPACK and DHCPNAK messages."

RFC 2131 states it MUST be included, and 2132 says "may optionally" be
included...

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Feb 2003 12:07:39 -0600

> 1) This introduces a new point of failure in a DHCP infrastructure.  
> If this particular relay goes down, then devices which currently hold 
> a lease cannot renew, where under standard DHCP, they would be able > to.

Not true.   They can still renew in the REBINDING state - just not in 
the RENEWING state.

Your observation about the wording of when the DHCP server should pay 
attention to this option makes sense, though - I wonder where that came 
from.

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