Subject: [Captive-portals] User equipment identification

From: Michael Schneider <[email-masked]>
Date: Fri, 3 Jul 2020 20:27:25 +0000

Hi,

I have read the documents about CAPPORT and as a Captive Portal vendor I find the current drafts very reasonable and well thought out. But a question came up when I was thinking about a dual stack user equipment. How does the client behave if it has an IPv4 and an IPv6 address and one of the two addresses is captive=false and the other captive=true. Do you see ways for the enforcement device to match these two addresses and allow both if one of them gets captive=false? Furthermore, a user equipment can hold more than one IPv6 address at a time and/or change it frequently.

Many thanks for your advice.

Regards,
Michael

--
onway ag
Michael Schneider
Head of Development

Stauffacherstrasse 16, CH-8004 Zürich
Tel: +41 55 214 18 35
[email-masked]
www.onway.ch

---

From: David Bird <[email-masked]>
Date: Fri, 3 Jul 2020 15:13:54 -0700

I believe how to uniquely identify the user device has been distinctly left
up to the implementers... It will depend on how you implement your DHCP and
ICMPv6 services and where you reside your API server (e.g. within or
outside any NATv4). Assuming you have full control of your DHCP server and
perhaps use RFC 8273 <https://tools.ietf.org/html/rfc8273>, you can assign
each subscriber a unique identifier during IP/prefix assignment. If that is
not an option, then the API server probably has only the connecting IP
address as the unique identifier...

On Fri, Jul 3, 2020 at 1:27 PM Michael Schneider <[email-masked]>
wrote:

> Hi,
>
> I have read the documents about CAPPORT and as a Captive Portal vendor I
> find the current drafts very reasonable and well thought out. But a
> question came up when I was thinking about a dual stack user equipment. How
> does the client behave if it has an IPv4 and an IPv6 address and one of the
> two addresses is captive=false and the other captive=true. Do you see ways
> for the enforcement device to match these two addresses and allow both if
> one of them gets captive=false? Furthermore, a user equipment can hold more
> than one IPv6 address at a time and/or change it frequently.
>
> Tel: +41 55 214 18 35 <+41%2055%20214%2018%2035>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: David Bird <[email-masked]>
Date: Fri, 3 Jul 2020 16:05:12 -0700

Over the years now :) - I've also thought vendors might use something like
"http://<special-hijack-ip>/" with a NAS-non-integrated DHCP/ICMPv6 server,
so that the NAS might redirect to the appropriate
https://api-server/?unique-device-session-identifier.

On Fri, Jul 3, 2020 at 3:13 PM David Bird <[email-masked]> wrote:

> I believe how to uniquely identify the user device has been distinctly
> left up to the implementers... It will depend on how you implement your
> DHCP and ICMPv6 services and where you reside your API server (e.g. within
> or outside any NATv4). Assuming you have full control of your DHCP server
> and perhaps use RFC 8273 <https://tools.ietf.org/html/rfc8273>, you can
> assign each subscriber a unique identifier during IP/prefix assignment. If
> that is not an option, then the API server probably has only the connecting
> IP address as the unique identifier...
>
> On Fri, Jul 3, 2020 at 1:27 PM Michael Schneider <
> [email-masked]> wrote:
>
>> Hi,
>>

---

From: Erik Kline <[email-masked]>
Date: Sun, 5 Jul 2020 23:18:35 -0700

> I have read the documents about CAPPORT and as a Captive Portal vendor I find the current drafts very reasonable and well thought out. But a question came up when I was thinking about a dual stack…

I had often thought that it's going to take mapping clients by L2
identifiers to really pull this off.  However, even if the on-site
infrastructure live-streamed the neighbor table to the enforcement
device/other elements, there's always the possibility it will not
really be sure about the MAC address of an IPv6 client until it has to
do ND for it to deliver a reply packet.

One client per L2 domain is an approach that I think solves this: each
IPv6 client gets its own /64 (see https://tools.ietf.org/html/rfc8273)
and then I think you can identify the IPv4 address and the IPv6 /64
addresses easily enough as being the same client.  This has some other
nice security properties as well.

2 cents,
-ek