[lacnog] IPv6 in Wifi Hotspots
Fernando Frediani
fhfrediani en gmail.com
Mie Oct 16 15:24:19 -03 2019
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 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.
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.
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.
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
> <http://vsz.fca.unicamp.br>&ssid=FCA6&mac=e0:10:7f:3f:69:30&url=http%3A%2F%2Fdetectportal.firefox.com
> <http://2Fdetectportal.firefox.com>%2Fsuccess.txt&proxy=0&vlan=3&wlan=12&sip=vsz.fca.unicamp.br
> <http://vsz.fca.unicamp.br>&sshTunnelStatus=1&uip=2801:8a:c040:200:1dd7:5af7:44fe:1b2b&StartURL=http%3A%2F%2Fwww.fca.unicamp.br
> <http://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 <mailto: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 <mailto: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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20191016/c09c9e6e/attachment.html>
Más información sobre la lista de distribución LACNOG