Implement DHCP Option 114 for captive portal detection

[AnthonyGrondin]

Not sure how this would be best done, since edge-captive and edge-dhcp are two distinctive crates.

DHCP Option 114 allows a DHCP server to provide a captive portal API URL during the DHCP handshake, which the device will query immediately. Although many devices still use the legacy HTTP probe to detect a captive portal, more and more device are moving over to prioritizing DHCP Option 114 for captive portal detection, as it is more reliable, and provides context specific information.

Resources:

• https://datatracker.ietf.org/doc/rfc8910/
• https://developer.android.com/about/versions/11/features/captive-portal

[ivmarkov]

Not sure how this would be best done, since edge-captive and edge-dhcp are two distinctive crates.

I don't see a problem.
edge-captive is just a pseudo-DNS server which resolves everything to the IP you had given it.

edge-dhcp is a DHCP client as well as a server. It is standard for the DHCP protocol to serve "extra data" beyond the strict IP configuration that a DHCP client is requesting.

For example, the DNS info that DHCP delivers to the client is such "extra data" that is not strictly necessary for the client w.r.t. its IP configuration.

Ditto for the captive portal URI you are requesting.

In the other direction (client-to-server), this is how the client reports to the server its host name, and then - if the DHCP server happens to be co-located with a LAN DNS proxy server, the DNS proxy server can get the hostname of your client and announce it on the local lan via DNS. If you've wondered how come you can "ping" your machines on the LAN without mDNS (i.e., the ".local" suffix), that's how that works.

In fact - DHCPv6 (which we don't support yet) has a special "stateless mode" of operation, where the DHCP server does not deal with assigning ipv6 IPs to the clients at all (this is better left to SLAAC and link-local IPv6 anyway).

This "stateless mode" (and thus the sole purpose of DHCPv6) is to serve you that "extra data" - which - most often than not - is the DNS servers as well as - I guess - your captive Portal URL.

DHCP Option 114 allows a DHCP server to provide a captive portal API URL during the DHCP handshake, which the device will query immediately. Although many devices still use the legacy HTTP probe to detect a captive portal, more and more device are moving over to prioritizing DHCP Option 114 for captive portal detection, as it is more reliable, and provides context specific information.

I've now implemented a quick extension in this branch along the lines of the quoted by you RFC, but I've not even tested it yet.
Maybe you can give it a try? If it works for you then I'll merge.

[ivmarkov]

Fixed by #31