Dual stack hotspot/captive portal

Jima jima at beer.tclug.org
Thu Feb 24 01:44:20 CET 2011


On 2/23/2011 1:18 PM, Ben Jencks wrote:
> On Feb 23, 2011, at 1:20 PM, Jima wrote:
>
>> On 02/23/2011 11:39 AM, Ben Jencks wrote:
>>> Does anyone have experience setting up dual stack captive portal systems, e.g. for wireless hotspots? The difficulty is in tying the user's identity (as they log into the portal) to *all* of their IP addresses. With v4 it's easy, they only have one address and it's the one they use to log into the captive portal. With dual stack they have at least two: v4 and v6, plus possibly v6 privacy addresses that change over time.
>>>
>>> The only option seems to be identifying users by MAC address post-login, but that's still imperfect. With v4 you can use the DHCP lease table to tie MACs to IPs, but with v6 the best I can think of is monitoring the neighbor table. Has anyone come up with any better solutions?
>>
>> I can't say I've done it or encountered any packaged solutions, but if
>> I were working on this, I'd take a serious look at shoehorning a bridge
>> (even a single-device bridge) into the mix and doing MAC-based
>> permissions via ebtables.  (Under Linux, anyway; I'm not sure what
>> approach I'd take under any other OS.)
>> Not the most helpful, I realize, but it might be someplace to start.
>
> MAC-based permissions will work fine (and I will probably do the authorization portion just like that), but that doesn't generate a log of IP addresses associated with that MAC. Not only do I have to make sure only authenticated users have access, I have to know which IP each user has, so we can tie any future abuse complaints back to the user.
>
> We're probably going to be doing something almost entirely homegrown; it won't use RADIUS but will integrate with an existing in-house application, so we have lots of flexibility in implementation.

  With IPv4 you could *generally* use DHCP logs to glean the MAC<->IP 
correlation, but one could easily bypass that by setting an IP manually, 
and that obviously doesn't help for IPv6 (especially RFC 3041 
addresses).  Maybe scrape ARP/neighbor tables periodically?  I did 
something similar for a coffee shop years ago (albeit only on IPv4 -- 
need to refresh that installation sometime).

      Jima



More information about the ipv6-ops mailing list