Peter Memishian writes:
>
> > 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.
The scope of what the daemon controls seems to be dependent on
implementation artifact rather than anything inherent about the
operation of the protocol, so that doesn't sound like the right answer
to me.
In other words, using this same principle, if the daemon were directly
in charge of NIS configuration, then any alteration in that
configuration away from the server-specified values should trigger
abandonment. But if the daemon set only the address and didn't try to
set the netmask and broadcast address (leaving those to someone else),
then it wouldn't pay attention to changes.
In the extreme, it'd be reasonable for the DHCP client to fetch data,
put it in a local store, and then configure _nothing_, allowing others
to pluck out desired data (address and all) and do with it what they
please.
For the opposite extreme, it seems as though DHCP consumers should be
on the lookout for manual changes to their parameters, and should fire
off a "dhcp drop" if users try to touch things. The fact that they
don't do this today would likely be (per the choice you're describing)
a "bug."
I don't see how "state that it believes it controls" is a dividing
line that an administrator should need to understand.
> > 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.
The toxic-server problem is one moderating issue, but I'm asking about
the principle behind the choice. I'm just not wild about the "server
thinks it configured them" argument.
There's an argument (albeit a weak one, I think) to be made that the
IP address is "special" because it's associated with a lease, unlike
all the other parameters, and thus touching that value has "special"
consequences. Maybe.
> 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.
A similar thing doesn't happen with ~IFF_UP change? Wouldn't the
acquisition of a new lease possibly change the address in that case,
and probably also cause IFF_UP to be reinstated?
Anyway, yes, I agree that'd be a bit annoying. The documentation
should be clear:
If you change a DHCP-configured parameter manually, your
change will remain in effect as long as the DHCP server
doesn't provide a different value for that parameter.
However, if the server changes the parameter on a subsequent
lease renewal -- which may well be days or weeks after you
last modified the value.
If you want your manually-configured values to remain in
force, you should use an infinite lease time, change the
server to provide the desired values, or terminate DHCP
service for that interface.
[This is where NWAM could insert an alternative based on
setting the desired override parameter as part of some
profile.]
--
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
