<div dir="ltr"><div>Frediani,</div><div><br>But I know hotspot scenarios that are implemented in L3 (DHCP Relay, for example). If so, how is MAC address authentication based? I understand that in this scenario, the IP address is authorized for packet forwarding, but not the MAC.<br><br></div><div>Regards,</div><div><br></div><div><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 11:52, Fernando Frediani <<a href="mailto:fhfrediani@gmail.com">fhfrediani@gmail.com</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>
For me it also makes more sense and simpler to whitelist the MAC <br>
address, but then what about the initial phase when the client has to <br>
talk to a web portal which may not be locally hosted ?<br>
<br>
Uesley - I understand authorizing MAC address is not on the Wireless <br>
layer (Access point) but on the main router the serves as the internet <br>
gateway using something like Layer 2 ACL<br>
<br>
Fernando<br>
<br>
On 17/10/2019 07:54, Fernando Gont wrote:<br>
> 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>
> 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>
> 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>
> 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>
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>