[squid-users] Dual-stack IPv4/IPv6 captive portal

[Steve Hill]

I'm wondering whether anyone has implemented a captive portal on a 
dual-stacked network, and whether they can provide any insight into the 
best way of going about it.


The problems:

- Networks are frequently routed with the proxy server on the border. 
This means the proxy doesn't get to see the client's MAC address, so 
captive portals have to work by associating the IP address with the 
user's credentials.

- In a dual-stacked environment, a clients' requests come from both its 
IPv4 address and IPv6 address.  Treating them independently of each 
other would lead to a bad user experience since the user would need to 
authenticate separately for each address.

- Where IPv6 privacy extensions are enabled, the client has multiple 
addresses at the same time, with the preferred address changing at 
regular intervals.  The address rotation interval is typically quite 
long (e.g. 1 day) but the change-over between addresses will occur 
spontaneously with the captive portal not being informed in advance. 
Again, we don't want to auth each address individually.

- Captive portals often want to support WISPr to allow client devices to 
perform automated logins.


Possible solutions:

- The captive portal page could include embedded objects from the 
captive portal server's v4 and v6 addresses.  This would allow the 
captive portal to temporarily link the addresses together and therefore 
link the authentication credentials to both.  The portal would still 
have to work correctly when used from single-stacked devices.  This also 
isn't going to work for WISPr clients since the client will never render 
the page when doing an automated login so we wouldn't expect any 
embedded objects to be requested.

- Using DHCPv6 instead of SLAAC to do the address assignment would 
disable IPv6 privacy extensions, which would be desirable in this case. 
  However, many devices don't support DHCPv6.

- The DHCP and DHCPv6 servers know the MAC and IPv[46] address of each 
client and could cooperate with each other to link this data together. 
However, the proxy does not always have control of the DHCP/DHCPv6 servers.


-- 
  - Steve Hill
    Technical Director
    Opendium Limited     http://www.opendium.com

Direct contacts:
    Instant messager: xmpp:steve at opendium.com
    Email:            steve at opendium.com
    Phone:            sip:steve at opendium.com

Sales / enquiries contacts:
    Email:            sales at opendium.com
    Phone:            +44-1792-824568 / sip:sales at opendium.com

Support contacts:
    Email:            support at opendium.com
    Phone:            +44-1792-825748 / sip:support at opendium.com