Peter Memishian writes: > > True ... I'm thinking about the limits so I know where we could be > > going and the principle behind the "don't mind that flag" change. > > To me, it's appropriate to abandon in cases where the interface's current > configuration has been made incompatible with the configuration the DHCP > client configured (and is supposedly maintaining as per IFF_DHCPRUNNING). > Clearing the IFF_UP flag doesn't render the configuration incompatible, > but just affects the ability for the DHCP client to renew the lease -- so > it seems preferable to just let that resolve itself per the protocol.
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? 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? 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.) -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
