RFC 8910

Ÿnérant <[email protected]> Wed, 20 Apr 2022 16:04:00 +0200

Newsgroups	gmane.network.dhcp.isc.dhcp-server
Message-ID	<90d1868be7901cd72bcecc7ce31632969ade8d8e.camel__21987.1722439834$1650463466$gmane$org@crans.org>

Hello!

For my organization, I am using isc-dhcp-server as DHCP server.

We want to deploy a captive portal for a new open Wifi to authenticate
users. However, we want to do it great, and avoid to do Man-in-the-
middle attacks to access the portal. The RFC 8910 let the DHCP server
to send an API URI that indicates the presence of a captive portal, and
let the clients to detect the presence of a captive portal and the URL
that let them to authenticate.

However, I think that the RFC is not implemented yet. The RFC replaces
the RFC 7710 (which added a captivep-portal-url option) and the RFC
3679, which added a default-url option. The present RFC overwrites this
option, number 114.

I just added in my configuration the following options:

option default-url "https://example.com/api.json";  # 114 from RFC3679
option v4-captive-portal "https://example.com/api.json";  # 160 from
RFC7710

These are recognized by isc-dhcp-server. But when I launch the server
and add a client, I don't see any of the two options when I analyse the
DHCP packets (with tcpdump or Wireshark for example). Did I make
something wrong? Is there something unimplemented?

One more question: does someone know how clients react to this DHCP
option? Who really cares about this URL? When is the client informed
that there is a captive portal, and how is they redirected?

Regards,

-- 
Yohann D'Anello

-- 
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users

signature.asc (application/pgp-signature, 833 B)