[lacnog] IPv6 in Wifi Hotspots

[Fernando Frediani]

Hi Uesley.

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.
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 ?

Fernando

On 17/10/2019 13:23, Uesley Correa wrote:
> Frediani,
>
> 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.
>
> Regards,
>
> Uesley Corrêa - Analista de Telecomunicações
> CEO Telecom Consultoria, Entrenamiento y Servicios
> CEO Telecom Fiber Solutions
>
>
> Em qui, 17 de out de 2019 às 11:52, Fernando Frediani 
> <fhfrediani en gmail.com <mailto:fhfrediani en gmail.com>> escreveu:
>
>     Hello Fernando.
>
>     For me it also makes more sense and simpler to whitelist the MAC
>     address, but then what about the initial phase when the client has to
>     talk to a web portal which may not be locally hosted ?
>
>     Uesley - I understand authorizing MAC address is not on the Wireless
>     layer (Access point) but on the main router the serves as the
>     internet
>     gateway using something like Layer 2 ACL
>
>     Fernando
>
>     On 17/10/2019 07:54, Fernando Gont wrote:
>     > Hello, Fernando,
>     >
>     > On 16/10/19 10:01, Fernando Frediani wrote:
>     > [....]
>     >> 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.
>     > Normally, the MAC address is whitelisted.
>     >
>     >
>     >
>     >> 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.
>     > The solution here is to "authenticate"/whitelist the MAC address, as
>     > opposed to the IPv{4,6} address. Firstly, because it might be
>     tricky to
>     > "log" both the IPv6 and IPv4 addresses employed. Secondly,
>     because as
>     > you correctly note, multiple addresses might be in use.
>     >
>     >
>     >
>     >> 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.
>     > Forget about dhcpv6. It is not widely supported -- unfortunately.
>     >
>     > P.S.: If you are charging users, please beware that newer
>     clients also
>     > do MAC address randomization. Some implementations use a scheme
>     similar
>     > to RFC7217 (but for mac addresses),and thus you get mac
>     addresses that
>     > are stable on a per-ap-basis. But others might use plain
>     randomization,
>     > and thus a reassociation might result in a new MAC addresses,
>     meaning
>     > that if e.g. credit was tied to the old mac address, things
>     might not
>     > work as expected.
>     >
>     > Thnx,
>     _______________________________________________
>     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
>
>
> _______________________________________________
> 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/20191017/ca7795d1/attachment.html>