<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Thanks for the inputs so far.</p>
<p>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.<br>
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.</p>
<p>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.</p>
<p>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.<br>
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.</p>
<p>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.</p>
<p>Fernando Frediani<br>
</p>
<div class="moz-cite-prefix">On 16/10/2019 14:14, Henri Alves de
Godoy wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CALRKgT6Mgd4odsmPdnbSzknJ+JdesHWiCGuYbfh4SPt_nT8Ysg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><span lang="en">Hi Fernando, Uesley and Jordi,<br>
<br>
I understand your question as it can clarify what I have been
doing here at the University.<br>
<br>
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.<br>
<br>
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.<br>
<br>
As I do not know which operating system of my visitor and I
have to enable dhcpv6 and necessarily radvd (because of
Android clients).<br>
<br>
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.<br>
<br>
Here's an example of a log via captive portal or hotspot if
you want to call it that.</span>
<div><br>
</div>
<div>Wed Oct 16 13:30:02 2019</div>
<div><br>
Acct-Session-Id = "5DA74532-8401D503"</div>
<div> Framed-IP-Address = 192.168.200.11 - <b>This is
the CLAT IP</b></div>
<div> Framed-Interface-Id = 1dd7:5af7:44fe:1b2b - <b>This
is the IPv6 Temporary Client </b></div>
<div> Framed-IPv6-Prefix = 2801:8a:c040:200::/64 - <b>This
is the IPv6 network </b></div>
<div> Acct-Multi-Session-Id =
"e0107f3f693a00234e5b789a5da74532040a"<br>
Acct-Link-Count = 1<br>
Acct-Status-Type = Start<br>
Acct-Authentic = RADIUS<br>
User-Name = "henri.godoy"<br>
Called-Station-Id = "E0-10-7F-3F-69-3A:FCA6"<br>
Calling-Station-Id = "00-23-4E-5B-78-9A" - <b> MAC
Client Device</b><br>
NAS-Port-Type = Wireless-802.11<br>
Connect-Info = "CONNECT 802.11b/g"<br>
Event-Timestamp = "Oct 16 2019 13:30:03 -03"<br>
Ruckus-SSID = "FCA6"<br>
Ruckus-BSSID = 0xe0107f3f693a<br>
Ruckus-VLAN-ID = 3<br>
Ruckus-SCG-CBlade-IP = 2886773770<br>
Proxy-State = 0x31<br>
NAS-IPv6-Address = 2801:8a:c040:fca1::4<br>
FreeRADIUS-Acct-Session-Start-Time = "Oct 16 2019
13:30:02 -03"<br>
Tmp-String-9 = "ai:"<br>
Acct-Unique-Session-Id =
"aec4dd2b04755858e966afebb33e366f"<br>
Timestamp = 1571243402<br>
</div>
<div><br>
</div>
<div><span class="gmail-tlid-translation gmail-translation"
lang="en">Apache captive portal access log</span> </div>
<div><br>
</div>
<div>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=<a
href="http://vsz.fca.unicamp.br" moz-do-not-send="true">vsz.fca.unicamp.br</a>&ssid=FCA6&mac=e0:10:7f:3f:69:30&url=http%3A%2F%<a
href="http://2Fdetectportal.firefox.com"
moz-do-not-send="true">2Fdetectportal.firefox.com</a>%2Fsuccess.txt&proxy=0&vlan=3&wlan=12&sip=<a
href="http://vsz.fca.unicamp.br" moz-do-not-send="true">vsz.fca.unicamp.br</a>&sshTunnelStatus=1&uip=2801:8a:c040:200:1dd7:5af7:44fe:1b2b&StartURL=http%3A%2F%<a
href="http://2Fwww.fca.unicamp.br" moz-do-not-send="true">2Fwww.fca.unicamp.br</a>
HTTP/1.1" 200 5291<br>
</div>
<div><br>
</div>
<div><span class="gmail-tlid-translation gmail-translation"
lang="en">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. :-(</span> </div>
<div><br>
</div>
<div>Regards,</div>
<div>Henri <br>
</div>
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Em qua, 16 de out de 2019
às 12:01, Fernando Frediani <<a
href="mailto:fhfrediani@gmail.com" target="_blank"
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 there<br>
I will put in English in order to facilitate for some in
the list and <br>
are english speakers which perhaps may also know about it.<br>
<br>
A while ago I asked about IPv6 in Hotspot environments and
some people <br>
responded that had it working but the thread never came to
a conclusion <br>
of what exactly is the key point for IPv6 to work in
Hotspot. I <br>
understand that some people may have public Wifi with IPv6
enabled which <br>
is not necessarily the same thing as a Hotspot system with
IPv6 which I <br>
am interested to know more about.<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. 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>
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 itself.<br>
<br>
Given that does anyone see any proper way for Hotspot to
work with IPv6 <br>
after a client is web authorized ?<br>
<br>
Regards<br>
Fernando Frediani<br>
<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>
</div>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">
<div>-- </div>
<div>Henri Alves Godoy</div>
<div>Tecnologia da Informação e Comunicação</div>
<div>Faculdade de Ciências Aplicadas - FCA</div>
<div>Universidade Estadual de Campinas - UNICAMP</div>
<div>Fone: (19) 3701-6682</div>
</div>
</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>