Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-server-override

From: Ted Lemon <[email-masked]>
Date: Thu, 3 Feb 2005 13:18:33 -0700

On Jan 24, 2005, at 5:08 AM, Ralph Droms wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override 
> -01.txt

A couple of minor problems.   First, the abstract is too long and  
contains references.   Second, the name of the option is 'server  
identifier', not Server-ID, at least in RFC2132.   The name used in  
this draft needs to be consistent with RFC2132.

Another more substantive problem is that relay agents frequently are  
configured to relay to more than one DHCP server.   This creates a  
problem - let's say the relay agent asks the DHCP server to insert a  
server-id option that's different than the server's usual identifier.    
Now the client replies, to the relay agent.   The relay agent forwards  
the DHCPREQUEST to all of the DHCP servers that it's configured to use,  
along with the modified server-identifier option and the  
server-id-override suboption.   At this point, all of the servers are  
directed to consider that the request is for them.   So this is a  
substantial change from the former behavior.

I'm not sure this is a showstopper, but I don't remember hearing it  
discussed, and it probably ought to be.

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

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 3 Feb 2005 22:41:09 -0500

First, another minor comment is that this draft is not up the current
standards for drafts (in terms of the boilerplate, especially the end
material).

The issue Ted raises is a good one and should be described. This option can
really only be used when the servers are able to support this capability and
are either part of a failover relationship or won't otherwise NAK each
other's leases.

HOWEVER, this requirement isn't significantly different from running
multiple servers for a network segment or segments when clients on those
network segment(s) are unable to RENEW and must REBIND. The only significant
difference being that clients will start having problems at T1 intsead of at
T2.

And, while not stated in the draft, it is always possible that the relay
keeps a mapping of the server for the address and only forwards unicast
client requests to that server. (Broadcast requests, or when mapping
information is missing?, would be relayed to all servers.)

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ted Lemon
> Sent: Thursday, February 03, 2005 3:19 PM
> To: [email-masked]
> Cc: Stig Venaas
> Subject: Re: [dhcwg] dhc WG last call on 
> draft-ietf-dhc-server-override
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 4 Feb 2005 10:34:05 -0700

> difference being that clients will start having problems at T1 intsead 
Okay, this isn't the problem I thought it was, because in the RENEWING 
and REBINDING states the client doesn't send a server identifier option 
anyway.   The only state where it's an issue is the SELECTING state.   
In that state, the difference in behavior is that both servers are 
going to see a server identifier and identify it as their own.   So a 
server that's written in such a way that it uses the fact that the 
server identifier matches as a way to decide whether to ack the lease 
might go down a weird code path.   It would probably work, but it might 
be worth mentioning in the draft that implementors need to be aware of 
this difference in behavior.   Personally, my experience with RENEW vs 
REBIND is that when one fails, it's RENEW that fails, not REBIND.

> information is missing?, would be relayed to all servers.)

I think it would be a mistake to require this, although it would might 
be a boon if a relay agent provided this capability as a possible 
optimization (reducing the renew workload on both servers).   But the 
server implementor can't assume that this will happen.   And anyway, it 
doesn't address the SELECTING case, because the DHCPREQUEST in the 
selecting case is broadcast, not unicast.

One thing the draft also doesn't address is whether the relay agent 
fills in giaddr.   I think it must fill in giaddr, because if it 
doesn't, the server will send the reply directly to the client, which 
means the relay won't have an opportunity to strip the relay agent 
information option.