> The other cases are less clear. Do we tear down the DHCP session if > someone deletes or modifies the default route that the server gives > us? Why not? Wasn't it part of the lease?
My rule wasn't tied to the lease contents, but rather to what the DHCP client itself was responsible for configuring. That is, it's only reasonable for it to enforce an "abandon" policy for state that it believes it controls. Of course, for physical IPv4 interfaces, the client does configure a default route, but I've always felt that was a bug. > Should we tear down when the user alters the broadcast address? Is > that really something that DHCP/BOOTP should have been distributing > via a parameter in the first place? > > How about the subnet mask? How tied to the lease itself is the > configured mask, and does it make sense that we throw up our hands if > that is changed? As above, I think the client would be within its rights to abandon if these change (since it configured them). However, pragmatically it's problematic because (as you pointed out earlier) the client admin is held hostage to toxic server configuration. > Each place I try the argument, it seems to me that it's hard to argue > that the right scheme is the current "my way or the highway" guarantee > that dhcpagent gives the user. I think we're left with sparring over > the IP address itself, but given the way other parameters are (or > should be) treated, I'm just hesitant to say that this one is in the > "unplumb" category. (Yes, I realize that changing the address would > very likely break renewal for most plausible server implementations, > but I'm suggesting that it poses problems that are roughly equivalent > to the ~IFF_UP plan. If you can't renew after a change, then so be > it.) My concern is that after the renew fails, the client will obtain a new lease and clobber the statically configured address. Given that the lease might be days or even weeks long, that's a long time between cause and effect -- and likely to be seriously inconvenient when it does occur. -- meem
