Hoping to summarize this thread;
- ICMP shouldn't carry and "configuration", but as notification only, it is no worse than traditional ICMP; draft update, thanks Warren.
- There is a concern in linking DHCP functions and captive portal. Perhaps, if the DHCP setting is always static (e.g. it is not used to indicate explicitly that certain devices are subject to CP and others, who might have "auto-authenticated", aren't), it becomes just configuration and not integration.
- There are concerns that DHCP isn't the only way to obtain network configuration... a couple suggestions:
-- In a different thread, .well-known URIs were suggested. The DHCP parameters could be IP addresses instead of URI (hmm, does the current draft really mean URL?) and the URI part is a .well-known
-- In the absence of the DHCP parameter, the default gateway is used.
Keep in mind, this CP-IP/.well-known/cp-redirect is the "entry" point to the CP. It is expected that the application answering will have the necessary information (like client MAC address, IP address, etc) to format the CP URL that otherwise would have been in a 302 redirect. so, the CP web application can, and should, be using HTTPS.
What capport-icmp brings is a means of CP notification - a more specific replacement for traditional Dest. Unreach. or TCP Reset, or simply dropped packets. Oh, and also a whole lot better than hijacking HTTPS :)