[ninkendo]

I wonder how captive portals are supposed to work with IPv6 temporary private addresses (RFC4941).

I’ve never run a captive portal but I always assumed that the router just redirects all port 80 packets to the portal (and rejects everything else), and then upon authenticating, the gateway puts your IP in the “allow” bucket and you get access.

But if you’re generating random addresses every few minutes, you’d need to continually reauthenticate, unless the system has some way of associating the temporary addresses with the original connection. Maybe it listens to ndp and uses MAC addresses to associate? That would be more advanced than most captive portals I’ve seen which seem to only care about ip addresses. Maybe just none of them use IPv6, or simply break with temporary addresses?

[mannyv]

In general they work by having an allow list and by using a captive DNS. Some will also try to redirect http/https.

Once the agreement is accepted the MAC is added to the allow list.

Not sure how MAC address randomization works in these schemes, but it does. There must be some standard algorithm that everyone follows.

[zamadatix]

There are 3 main types of "random Wi-Fi MAC addresses". The most well known one is randomization of the MAC while the client is probing from SSIDs (prior to connection). This has been around for many years and doesn't change the actual connection MAC later on. Another randomization type that's slightly more common these days (e.g. iPhones default to it now) is choosing a random MAC per SSID. That way you can't be tracked by MAC across multiple networks but you still have consistency for captive portals and business networks. The third is true rotating randomization - this is relatively uncommon as it breaks captive portals (there is no well known algorithm or it'd be relatively pointless). iPhones were going to adopt this with rolling MACs but it was too broken and offered little over approach 2 in terms of privacy.

[ninkendo]

I guess different captive portals work differently, because I’ve heard of plenty of them that can be bypassed by simply statically assigning the address of someone else who’s already authenticated (ie session hijacking), but it makes sense that any “decent” captive portal system uses MAC addresses to mitigate this.

The randomization I refer to is of the outgoing IPv6 address, not the MAC address… nothing that I’m aware of randomly cycles MAC addresses (Apple’s OSes can be configured to randomly generate a MAC every time you connect to a network, but it won’t regenerate them continuously in a session. IPv6 addresses however are continuously generated, as per the RFC4941 spec.) If the system is using MAC addresses to identify users, then temporary/cycled IPv6 addresses should be no problem.