[lacnog] IPv6 in Wifi Hotspots

Jue Oct 17 06:45:18 -03 2019

Hi Fernando,

El 16/10/19 20:24, "LACNOG en nombre de Fernando Frediani" <lacnog-bounces en lacnic.net en nombre de fhfrediani en gmail.com> escribió:

Thanks for the inputs so far.

Jordi - Getting the addresses via the portal and tie them to the MAC Address may be something that works, but although you don't see a problem with IPv6 Temporary 

Actually, I’m convinced is the only way (MAC addresses), as this is the only way that allows the captive portal to keep working even if users or apps make anything with IP addresses. See what Henri posted.

Addresses I think that should be a concern until 100% resolved , even for a few applications otherwise there will be internet browsing problems. As it is a feature of the Operating System it's harder to have a fix in the authorization system.

Is not just OS, is apps the ones that can choose what addresses to use (temporary vs non-temporary, IPv6 vs IPv4), but I’ve not yet seen “general” apps that use the non-temporary ones and work with non-persistent addresses. It doesn’t make sense, it will be a clear software design bug.

Perhaps considering only one address initially (the one that talks to the authorization portal) to authenticate the client and then, after authorized, add a Layer 2 rule to allow everything coming from the MAC Address may be the way to a solution.

You can make sure about that by double checking (as I explained before, having in the portal IPv4-only objects and IPv6-only objects), if both of them match with the same MAC address (they should!).

Regarding the /64 per client I don't think that can be done only via RA at the moment and would require DHCPv6-PD which then is a problem for Android clients and therefore a showstopper.

Read the RFC, it is just RA. This is being used actually by some hot-spot providers. I cannot provide more details, just that it is done with Nokia devices. Anyway, I guess you are interested in using OpenSource, so Nokia details not so useful.

Henri - I am not sure I fully understood your solution and how you the system is able to authorize the client if via the Temporary IPv6 he is talking to the portal or other method. I guess DHCPv6 wouldn't make much difference in this case, again, due to Android clients.
I believe the Radius Attribute Framed-IPv6-Prefix is only for DHCPv6 scenarios and not all end-user Operating Systems take that into consideration by default, specially if there is no DHCPv6 Client at all. Still if the client received and configures the interface with the Framed-IPv6-Prefix it may not necessarily use it for browsing and may just use the Temporary IPv6 Addresses. The way to resolve that would be to use RA with Managed flag which, once again, would break Android usage.

Welcome more comments about these various scenarios and what you believe would be best approach to resolve these scenarios from a more conceptual point of view in order to have a fully functional IPv6 Hotspot system.

Fernando Frediani

On 16/10/2019 14:14, Henri Alves de Godoy wrote:

Hi Fernando, Uesley and Jordi,

I understand your question as it can clarify what I have been doing here at the University.

I am enabling in some access points the use of 464XLAT via captive portal via web, for students to authenticate with username and password. I understand it works like a hotspot, which is your question.

Both the wireless controller, the apache portal webpage and also the radius server are ipv6 enabled. The user when connecting he accesses the captive portal peacefully via ipv6 and authenticates. All this operation from what I tracked is being done by Temporary IPv6 acquired via stateless.

As I do not know which operating system of my visitor and I have to enable dhcpv6 and necessarily radvd (because of Android clients).

One of my concerns about identifying users in IPv6 for a future audit seems to be being resolved with the log I have gotten from radius in this update, which I did not have before and that will definitely help me.

Here's an example of a log via captive portal or hotspot if you want to call it that.   

Wed Oct 16 13:30:02 2019

        Acct-Session-Id = "5DA74532-8401D503"

        Framed-IP-Address = 192.168.200.11    - This is the CLAT IP

        Framed-Interface-Id = 1dd7:5af7:44fe:1b2b - This is the IPv6 Temporary Client 

        Framed-IPv6-Prefix = 2801:8a:c040:200::/64  - This is the IPv6 network 

        Acct-Multi-Session-Id = "e0107f3f693a00234e5b789a5da74532040a"
        Acct-Link-Count = 1
        Acct-Status-Type = Start
        Acct-Authentic = RADIUS
        User-Name = "henri.godoy"
        Called-Station-Id = "E0-10-7F-3F-69-3A:FCA6"
        Calling-Station-Id = "00-23-4E-5B-78-9A"  -  MAC Client Device
        NAS-Port-Type = Wireless-802.11
        Connect-Info = "CONNECT 802.11b/g"
        Event-Timestamp = "Oct 16 2019 13:30:03 -03"
        Ruckus-SSID = "FCA6"
        Ruckus-BSSID = 0xe0107f3f693a
        Ruckus-VLAN-ID = 3
        Ruckus-SCG-CBlade-IP = 2886773770
        Proxy-State = 0x31
        NAS-IPv6-Address = 2801:8a:c040:fca1::4
        FreeRADIUS-Acct-Session-Start-Time = "Oct 16 2019 13:30:02 -03"
        Tmp-String-9 = "ai:"
        Acct-Unique-Session-Id = "aec4dd2b04755858e966afebb33e366f"
        Timestamp = 1571243402

Apache captive portal access log 

2801:8a:c040:200:1dd7:5af7:44fe:1b2b - - [16/Oct/2019:13:29:31 -0300] "GET /wifi/portal/fca/&nbiIPv6=2801:8a:c040:fca1::4&client_mac=00:23:4e:5b:78:9a&reason=Un-Auth-Captive&wlanName=FCA6&dn=vsz.fca.unicamp.br&ssid=FCA6&mac=e0:10:7f:3f:69:30&url=http%3A%2F%2Fdetectportal.firefox.com%2Fsuccess.txt&proxy=0&vlan=3&wlan=12&sip=vsz.fca.unicamp.br&sshTunnelStatus=1&uip=2801:8a:c040:200:1dd7:5af7:44fe:1b2b&StartURL=http%3A%2F%2Fwww.fca.unicamp.br HTTP/1.1" 200 5291

With this information I have been able to relate the client's IPv6 with the name of the user who authenticated the mac address and the times, in case there is any case that we have to investigate. If the IP to be investigated is from the IPv4 pool and has been translated, then the work is a bit more boring because we have to check Jool's logs to find IP + Port. :-( 

Regards,

Henri 

Em qua, 16 de out de 2019 às 12:01, Fernando Frediani <fhfrediani en gmail.com> escreveu:

Hello there
I will put in English in order to facilitate for some in the list and 
are english speakers which perhaps may also know about it.

A while ago I asked about IPv6 in Hotspot environments and some people 
responded that had it working but the thread never came to a conclusion 
of what exactly is the key point for IPv6 to work in Hotspot. I 
understand that some people may have public Wifi with IPv6 enabled which 
is not necessarily the same thing as a Hotspot system with IPv6 which I 
am interested to know more about.

What comes to my mind and one of the key points is the web 
authorization. In a IPv4 environment the client gets its IPv4 address 
via traditional DHCP and after web authorization that address is 
permitted to go out to the internet. In IPv6 we have RA where the client 
assigns its own IPv6 Address in stateless autoconfiguration. The web 
authorization system could in theory get the IPv6 address the client is 
talking and authorize it but there is also the figure of multiple and 
Temporary IPv6 Addresses which may break this.

If DHCPv6 only was enabled though Managed RA flag then some clients like 
Android would not work.
For me the only thing that comes to mind is the Hotspot to work in Layer 
2 authorizing the MAC Address and not the IP address however in that 
case there may be a problem with access to the authorization website itself.

Given that does anyone see any proper way for Hotspot to work with IPv6 
after a client is web authorized ?

Regards
Fernando Frediani

_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog

-- 

-- 

Henri Alves Godoy

Tecnologia da Informação e Comunicação

Faculdade de Ciências Aplicadas - FCA

Universidade Estadual de Campinas - UNICAMP

Fone: (19) 3701-6682

_______________________________________________
LACNOG mailing list
LACNOG en lacnic.net
https://mail.lacnic.net/mailman/listinfo/lacnog
Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
_______________________________________________ LACNOG mailing list LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20191017/6e63a862/attachment-0001.html>