<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Uesley.</p>
<p>Yes you are correct and I have the same understanding. If the
scenario works based on L3 that is the way, and MAC Address
authorization is not an option or at least would become much
difficult to be made distributed.<br>
My doubt is where L2 ACL is possible (which in theory simplifies
things) how would work the authorization for the client to talk
only to the authorization portal initially and them to forward
packets to the internet afterwards ?</p>
<p>Fernando<br>
</p>
<div class="moz-cite-prefix">On 17/10/2019 13:23, Uesley Correa
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJvMJMSrqhn6rB2yyDV019F3mS7sz_9HDVfxwuP2RGoJhAxGtw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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"
moz-do-not-send="true">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a
href="https://mail.lacnic.net/mailman/options/lacnog"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mail.lacnic.net/mailman/options/lacnog</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LACNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LACNOG@lacnic.net">LACNOG@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/lacnog">https://mail.lacnic.net/mailman/listinfo/lacnog</a>
Cancelar suscripcion: <a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/options/lacnog">https://mail.lacnic.net/mailman/options/lacnog</a>
</pre>
</blockquote>
</body>
</html>