<div dir="ltr">Hello everyone,<br><br>With the ability to authorize via MAC Address, what would roaming between hotspot cells look like? Or would all cells be in the same L2 segment?<br><br>Regards,<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Uesley Corrêa - Analista de Telecomunicações</div></div></div><div>CEO Telecom Consultoria, Entrenamiento y Servicios</div><div>CEO Telecom Fiber Solutions</div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui, 17 de out de 2019 às 08:02, Fernando Gont <<a href="mailto:fernando@gont.com.ar">fernando@gont.com.ar</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello, Fernando,<br>
<br>
On 16/10/19 10:01, Fernando Frediani wrote:<br>
[....]<br>
> What comes to my mind and one of the key points is the web<br>
> authorization. In a IPv4 environment the client gets its IPv4 address<br>
> via traditional DHCP and after web authorization that address is<br>
> permitted to go out to the internet. <br>
<br>
Normally, the MAC address is whitelisted.<br>
<br>
<br>
<br>
> In IPv6 we have RA where the client<br>
> assigns its own IPv6 Address in stateless autoconfiguration. The web<br>
> authorization system could in theory get the IPv6 address the client is<br>
> talking and authorize it but there is also the figure of multiple and<br>
> Temporary IPv6 Addresses which may break this.<br>
<br>
The solution here is to "authenticate"/whitelist the MAC address, as<br>
opposed to the IPv{4,6} address. Firstly, because it might be tricky to<br>
"log" both the IPv6 and IPv4 addresses employed. Secondly, because as<br>
you correctly note, multiple addresses might be in use.<br>
<br>
<br>
<br>
> If DHCPv6 only was enabled though Managed RA flag then some clients like<br>
> Android would not work.<br>
> For me the only thing that comes to mind is the Hotspot to work in Layer<br>
> 2 authorizing the MAC Address and not the IP address however in that<br>
> case there may be a problem with access to the authorization website<br>
> itself.<br>
<br>
Forget about dhcpv6. It is not widely supported -- unfortunately.<br>
<br>
P.S.: If you are charging users, please beware that newer clients also<br>
do MAC address randomization. Some implementations use a scheme similar<br>
to RFC7217 (but for mac addresses),and thus you get mac addresses that<br>
are stable on a per-ap-basis. But others might use plain randomization,<br>
and thus a reassociation might result in a new MAC addresses, meaning<br>
that if e.g. credit was tied to the old mac address, things might not<br>
work as expected.<br>
<br>
Thnx,<br>
-- <br>
Fernando Gont<br>
e-mail: <a href="mailto:fernando@gont.com.ar" target="_blank">fernando@gont.com.ar</a> || <a href="mailto:fgont@si6networks.com" target="_blank">fgont@si6networks.com</a><br>
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1<br>
<br>
<br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote></div>