I agree with your assessment here.> > From a security perspective, what is the difference between: > > A) a router listening on 10.0.0.1 and allocating DHCPv4 address in a > similar range, asking people to configure it using http://[10.0.0.1] > B) the same thing using link local address, with the router being > configured using fe80::1 and asking people to configure it using > http://[fe80::1] C) the same replacing link local by ULAYour example B is exactly what I am suggesting, a it is identical to A in an IPV6 world.As already pointed out in this same thread, link-local addresses do NOT work in most web browsers, as you need to know which local interface to use - not suited at all within a for-dummies installation guide. ULAs will not fit the bill either because the prefix ought to be pseudo-random, and different for each and every shipped box. GUAs do not fit as they also depend on the customer, and by definition, are not available until the CPE has been successfully configured. Site-local addresses would have worked, but they're now deprecated. Multicast service discovery does not work because it is not implemented with current hosts - if we specify if now, it will be years before it can be used. So... you're stuck instructing the customer to use the constant IPv4 address. That works today and will continue to work for the foreseeable future of dual-stack hosts on unmanaged networks.
As much as I believe the CPE ought to provision a permament ULA prefix, I also believe the initial configuration argument is completely bogus.
Bogus or not, this seems to be one of the problems that was being addressed by this draft. We need to look at 2 things: 1. What is the problem being pointed out and what solutions are available to fix it? 2. Is this a big enough problem to be worth our time in addressing. You seem to have done a good job on number 1, now the WG needs to decided on number 2.