[lacnog] IPv6 in Wifi Hotspots
Henri Alves de Godoy
henri.godoy en fca.unicamp.br
Mie Oct 16 16:43:56 -03 2019
Hi Fernando,
If it is dhcpv6 or radv (Android) the radius server through the captive
portal (hotspot) registers the temporary IPv6 address the same way. I also
thought it was only for dhcpv6, but clients assigned with radv, radius
server also registers.
Follows log of an authentication via a smartphone with Android WiFi in the
hotspot.
Wed Oct 16 16:11:26 2019
Acct-Session-Id = "5DA76A93-BDBC3E01"
Framed-IP-Address = 192.168.200.10
Framed-Interface-Id = f073:ec0c:77a3:cbae
Framed-IPv6-Prefix = 2801:8a:c040:200::/64
...
...
Called-Station-Id = "F0-B0-52-1E-8E-9E:FCA6"
Calling-Station-Id = "F0-D7-AA-53-82-FC"
So far from what I understand and have seen, most connections originate
using Temporary IPv6. I will do a test by disabling the temporary IPv6 on
the client and leaving only the address delivered by radv, to see how
navigation and accounting behaves.
Regards,
Henri.
Em qua, 16 de out de 2019 às 15:24, Fernando Frediani <fhfrediani en gmail.com>
escreveu:
> 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&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 listLACNOG en lacnic.nethttps://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
>
--
--
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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20191016/76130bf3/attachment.html>
Más información sobre la lista de distribución LACNOG