[isf-wifidog] Implementing ipv6 support on wifidog

[Geneviève Bastien]

Hi,

Thank you all for your feedback and suggestions.  Let's continue this
debate.  I personnally don't know much about either tinyproxy, ipset or
even ip[6]tables.

But here are some thoughts, from all the comments:

- ipv6 support will require some work, even if we decide to go ip6tables,
it will be like a second redirect mechanism, maybe double the
configuration options.
- We have to write something for ipv6 anyway, so if it is possible to have
a solution that would work the same with ip4, then great, all the best!
- And if we can make it compatible with pfsense and FreeBSD, or at least
make it easier to port, all the best!
- We might loose some of the code stability/maturity, but not all, just
for the redirecting part, but we don't have any ipv6 stability anyway...

I'll start a branch for ipv6 support on the svn.


Thanks,
Geneviève


Some doc about the gateway:
The authentication process:
http://dev.wifidog.org/wiki/doc/developer/FlowDiagram

The firewall map of wifidog
http://dev.wifidog.org/attachment/wiki/doc/wifidog_firewall_diagram.png


> Hi.
>
> 2011/2/14 Jean-Philippe Menil <jean-philippe.menil at univ-nantes.fr>:
>> Le 14/02/2011 15:49, Andrew Niemantsverdriet a écrit :
>>>
>>> Hi
>>>
>>> 2011/2/14 Jean-Philippe Menil<jean-philippe.menil at univ-nantes.fr>:
>>>>
>>>> Le 14/02/2011 14:03, Marc Blanchet a écrit :
>>>>>
>>>>> sorry to be late on this thread.
>>>>> - nat is not what a captive portal does. captive portal intercepts
>>>>> dns
>>>>> request and then after authentication modify firewall rules to let it
>>>>> go
>>>>> through. so ipv6 will be no different.
>>>>> - however, something really different in IPv6 is the fact that the
>>>>> gateway
>>>>> receives a prefix from the DHCPv6 server. The prefix is then used for
>>>>> the
>>>>> internal network using router advertisements sent by the gateway. And
>>>>> the
>>>>> gateway does not do any NAT, only forwarding. So in the design, you
>>>>> must
>>>>> consider that.
>>>>>
>>>>> Marc.
>>>>>> On 2011-02-12 13:02, Andrew Niemantsverdriet wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> 2011/2/12 Jean-Philippe Menil<jean-philippe.menil at univ-nantes.fr>:
>>>>>>>>
>>>>>>>> Le 11/02/2011 20:30, Geneviève Bastien a écrit :
>>>>>>>>>
>>>>>>>>> ip6tables uses filtering, based on the ip address, instead of
>>>>>>>>> nat,
>>>>>>>>> and you
>>>>>>>>> can still build firewall and routing rules with it.
>>>>>>>>>
>>>>>>>>> But I'll take a look at tproxy and ipset and see if it would work
>>>>>>>>> best for
>>>>>>>>> wifidog.
>>>>>>>>>
>>>>>>>>> Geneviève
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Le 11/02/2011 17:01, Geneviève Bastien a écrit :
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> We'll soon start working on implementing the ipv6 support on
>>>>>>>>>>> the
>>>>>>>>>>> wifidog
>>>>>>>>>>> client. One of the problematic will be to port to ip6tables the
>>>>>>>>>>> actual
>>>>>>>>>>> iptables that wifidog creates at startup, so that all the
>>>>>>>>>>> redirects
>>>>>>>>>>> still
>>>>>>>>>>> work on ipv6.
>>>>>>>>>>>
>>>>>>>>>>> Can anyone help with that?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Geneviève
>>>
>>> <snip>
>>>>
>>>> Hi,
>>>>
>>>> maybe i'm misunderstood.
>>>> But with the actual wifidog, a client do a http request, request which
>>>> is
>>>> "natted" to the 2060 port, port on wich the wifidog daemon is listen
>>>> to.
>>>> Without this nat rule, you don't have any redirection.
>>>>
>>>> Regards.
>>>
>>> Jean Philippe,
>>>
>>> You are correct. IPv6 has no concept of NAT so the current way wifidog
>>> works is not possible. However (correct me if I am wrong) ipv6tables
>>> do support the queue mechanism. That would allow us to mark the
>>> packets and pass them into user space. From there a proxy of some sort
>>> could be used to implement the actual captive portal and when the user
>>> authenticates the queue rule could be removed.  Similar to what
>>> wifidog does now.
>>>
>>> Thanks,
>>>  _
>>> /-\ ndrew
>>
>> Yes,
>>
>> but if you do that, there will be two mechanism of redirection, one for
>> ipv4
>> (wifidog dameon listen on port 2060), another for ipv6 (local proxy or
>> whatever).
>>
>> It will be good to have an unique mechanism working with both ipv4/ipv6.
>> Maybe it will a good idea to look at the tproxy target.
>>
>> I've see a interesting feature with rahunas (see rahunas.org). It's
>> working
>> with ipset.
>> Maybe another way to do it.
>>
>> In fact, i'm very interesting to work on ipv6 support.
>>
>>
>> Regards.
>
> Jean Philippe,
>
> ipv4 iptables contains the queue target as well. So the same mechanism
> would work for both, I think. However that being said after having
> researched the TPROXY target more I agree that it might be the way to
> go. I have not heard of ipset however it looks very interesting. I too
> would be interested in working on IPv6 support and have one other
> person that works for me who would be too.
>
> I would be interested in seeing what the design goals.
>
> Thanks,
>  _
> /-\ ndrew
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>