dhcp-users RFC3315 DECLINE definition

[Simon Hobson]

"Mudric, Dusan (Dusan)" <dmudric at avaya.com> wrote:

> Benefits are clear.

It would appear that you are in a inority of one on that.

>> As above, you do **NOT** want that. Your network monitoring will tell you *ONCE* that the router is down, that is far >more useful than flooding your ticketing system with thousands of alerts which **CANNOT** tell you that the router is >down (there may be another reason).
> 
> This is not the point. It is not about finding the router problem. It is about finding a client that becomes unreachable and the reason why.

The ONLY reasons you have come up with are :
1) A router goes away - so it **IS** about finding the router problem and network monitoring tools will do that for you.
2) The admin misconfigured the network - and as has already been said, checking/testing your config after config changes is part of the admin's role. As an admin, I can tell you that having tools that try and second guess what you are trying to do and complain about stuff you know is actually what you want to do is a real PITA, more so than not spotting errors.

Example - at one time, some Netgear routers would not accept any address ending in .0 as bing a valid address - this was for setting the addresses from which admin was allowed. Once you get to a network of at least /23 size, then that test is simply not valid, and for networks smaller than /24, then other addresses are (in theory) not valid.
But the router CANNOT know anything about those other addresses - so the test was meaningless, but simply got in the way of valid configs.


> This is about the intelligent device helping identify which address is not useable for a device or application operation. As you can see, I did not list quite a few address types that some applications would never use. It is to the operators discretion to configure the address list. It would be unwise to allow to assign a multicast address to a device, or LL if the devices has to be globally reachable (device would already have one LL and does not need another one). That is why I gave examples above.

I think you've just proved my point there.
If the admin has to configure the client with a list of what is considered "valid" (for whatever definition of valid is decided on) then what's the point ? You have a catch 22 where you have to configure the client before you can automatically configure the client. If the defaults change (a prefix is brought into use or deprecated) then you really can get a situation where a device cannot be configured before it's been configured.
And that's leaving aside the "creative" way vendors can find to interpret standards !

By way of example, many years ago I had a printer that just wouldn't configure via DHCP. I checked and checked, but it just wouldn't accept a lease. In the end I had to manually configure it - so that a nuisance having to manually configure it, and an ongoing management issue in that it needs further manual intervention if the network changes (and that network did get renumbered).
Some time later, quite by accident while I was looking for something else, I found a comment to the effect that it would only accept a lease with a lease time over 2 years - I bet someone somewhere had a burning sensation in his ears as I questioned his (or her) parentage.

I don't want random problems like that - and you are proposing to build into the standard that the client, in the absence of any knowledge about what the admin intends, makes decisions about what it acceptable.


And you have still not defined what is considered acceptable. Forget the wooly talk of "unroutable" - you need to come up with an exact specification that says : apply test X where X is a clearly defined set of conditions.


And, you are concentrating on "when a client gets an address". So what if the router is there, and is advertising a prefix, AT THE TIME THE CLIENT IS CONFIGURED ? It'll accept the address.
The router now goes away - now what ? The time for sending a DHCP Decline message is long gone - it could have been weeks ago. So your proposal does nothing UNLESS at least one client tried to get/renew a lease during the time that router is down. So as a means of alerting to the router going down, on a stable network it has "limited" use - it could be hours or even days before it gets reported.
Network monitoring tools are there for that - and will report in whatever timescale the tool has been configured to act.

You also haven't addressed the case of the router being required in order to get requests to the server. So router down, client tried to get an address, but can't. Client is just as unreachable as in your scenarios, but cannot report anything. Again, properly setup networking tools will.


And (from memory) you also haven't said what the server should do with this information other than just logging it (something I'd just redirect to /dev/null). Should it flag the address as "unusable" so it doesn't get handed out to the next client asking for an address ? If so, then a temporary router issue could well poison the address pool, requiring manual cleanup, and until cleaned up, promoting more client address churn (that's what happens when the ISC DHCP4 server gets a reply when it does it's "ping before offer" check).