As in the subject, my request is for an IPv6 enabled hotspot, either dual stacked or IPv6 only.
Best solution would be to allow both IPv4 and IPv6 enabled users to access however one hotspot for each would be a good start.
I’ve previously emailed this request to Mikrotik who have indicated they are working on this, but I’m reposting here to get a feel from others as to who is interested in this becoming a reality for v5 and to indicate that I would be more than willing to test any Alpha or Beta releases of an IPv6-hotspot package soon as it becomes available.
Since this is a feature we need I have been giving this some consideration.
I have developed the back end software / client hotspot website, radius servers etc that run our hotspots. So I am keen to see how we can support IPv6 clients on our hotspot networks.
Since I don’t now the internal workings of RouterOS code I am making quite a few assumptions here. Perhaps someone from Mikrotik can set me straight where I get it wrong.
I assume that the easiest thing for Mikrotik to do is to copy the IPv4 Hotspot and make an IPv6 copy of the same thing that works on the IPv6 Protocol with the IPv6 Firewall.
There are three ways that the hotspot could be setup.
IPv4 Only
Ipv6 Only
Ipv4 + Ipv6 Dual Stack.
If the software is pretty much copied from IPv4 to IPv6 for the hotspot that will take care of the single stack (Option 2 above) senario.
For Option 3 the question becomes,
a) how does the dual stack client login to both IPv4 and IPv6 Hotspots
b) do the two hotspots have independant radius / user stats sessions or combined
For 3a) currently (on our system anyway) client initally hits the mikrotik login.html which redirects to our hotspot website where the client must purchase time&data the when they click the connect button to continue we redirect them back to the mikrotik alogin.html with radius credentials so that the client can be logged in via radius. At this point the status.html pops up in a new window and the main window redirects to the initial page the client requested. I invisige that another redirect happen here that also make a call to a mikrotik blogin.html to do an IPv6 radius or whatever login. This second redirect would be to an IPv6 Address to the the mikrotik could discover the IPv6 Address Associated with the client in addition to the IPv4 Address. A session token could be passed to both the IPv4 alogin.htm and the IPv6 blogin.html, so the router can know which IPv4 belongs with which IPv6.
For 3b) To have combined sessions the IPv4 counters would have to be combined with the IPv6 counters to create a single radius session. ie instead of IPv6 creating it’s own radius session, it would simply add itself to the existing IPv4 session. I have a feeling that this might be tricky to achieve without some effort. The main problem I see with this is that it creates the idea of a master and slave protocol. Let’s suppose that a client first starts his session with a call to an IPv6 web site such as http://ipv6.google.com, but the IPv4 is the master protocol, then the hotspot will have to redirect the browser to the IPv4 hotspot and login from there. I’m not really sure how much of a problem this is, or if it even is one.
Naturally I am happy to assist with testing this new feature.
Not really, most of the rules are simply catch-all redirects..
Eg: if dst-port=80 and protocol=tcp and user=no-auth then redirect to 65XXX (whatever port it is the hotspot runs on)
same with dns, redirect any port 53 udp requests to the mikrotiks IP address itself.
Those redirects are NAT. The destination IP address of the packet is rewritten to an IP address local to the router. From the iptables man page:
REDIRECT
This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only called from those chains. It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface (locally-generated packets are mapped to the 127.0.0.1 address). It takes one option:
–to-ports port[-port]
This specifies a destination port or range of ports to use: without this, the destination port is never altered. This is only valid if the rule also specifies -p tcp or -p udp.
It’s been suggested that the lack of a NAT capability for IPv6 is a roadblock for IPv6 Hotspot. Here is an implementation of NAT allowing IPv6 Redirect.
The Pepperspot solution was kinda neat in a way. They appear to be routing all IP traffic (v6 and v4) across a TUN interface so that it is consumed in userland by their Hotpot process. That process then puts packets out on the physical interface for authenticated clients. No NAT required. On the other hand, the process always consumes all packets so I would think performance is fairly bad.
At least that is how I think it works. Didn’t have too much time to go through their code, and I’m a very bad programmer to boot.
Actually it only captures IPv6 traffic that is directed to the QUEUE target in iptables, so it’s not all traffic.
And that is the one reason why it is better than the pepperspot solution.
The other reason is that pepperspot will only work on the direct LAN so hotpsot users can’t be behind another router.
The Juniper Junos Captive Portal has a similar problem.
You would not actually have to use the nat software I provided, you could just process the QUEUE traffic in userspace in your own code.
