Re: [dhcwg] RFC3315 DECLINE definition

[Simon Hobson <[e-mail]>]

"Mudric, Dusan (Dusan)" <[e-mail]> wrote:

> One server is configured to statically assign IPv6 addresses (based on the client MAC) or with a pool of IPv6 addresses for the local link. If a client on that location assigns the misconfigured address it becomes unreachable. A user does not even know how to spell DHCPv6 and all he/she experiences is that the device is unusable. The network operator does not get any indication that the device is out of service.

And just how does the client differentiate between that being a deliberate policy choice by the admin (perhaps that location is not supposed to have outside IPv6 connectivity) and a server misconfiguration ?
Besides, just how is that different from other (eg DHCP4) setups ? If I configure the HCP server to give the wrong router address then clients get broken network configs.

At the end of the day, unless you are going to build an all-knowing, globe spanning, AI service that auto-configures everything - then you have to allow for admins to have some intelligence and some competency in their work. So far I've seen nothing in your suggestions that goes beyond "the admin may make a mistake and then things are broken". yes we can make mistakes - but finding and dealing them is part of the job.

So, other than "the admin may make a mistake", what use cases do you have ?



"Mudric, Dusan (Dusan)" <[e-mail]> wrote:

> The application does the semantic check for the address and, if the address is semantically correct, checks if the device using the offered address can be reached within the domain the in which device has to communicate. If, for example, the device has to be globally reachable, the address has to be an unreserved, or not deprecated, global address.

You have **NOT** described anything related to whether the address issued is usable at the network level, basically at the level DHCP is working at. By your own admission, the device **DOES** have a valid working address, but for some reason the **APPLICATION** cannot use it. The **APPLICATION** should report that there is a communications problem - this is how it works normally. The address may well be perfectly usable for other traffic.

Part of troubleshooting such an issue is to look at the network connectivity and the requirements of the application. This sounds very much like the refrain you hear from users who declare "the internet is down" because the web page they are trying to reach isn't working.