Re: [Captive-portals] Questions about PvD/API

[Erik Kline <[e-mail]>]

On 31 August 2017 at 22:04, David Bird <[e-mail]> wrote:
> I will add Vincent's (valid) concern about API/PvD: It requires either
> polling or push (over TCP, which does require keepalive for NAT traversal),
> which means stations likely do not go idle on the network, and, in cases
> where a captive portal is possible, but not probable, UEs still have to
> maintain this API/PvD association if they want to ever get notified.

<no hats>

This is a limitation of the current PvD proposal: it's rather
DHCPv6-like in that it lacks a mechanism to inform either all clients
or even a single client of a change in state.

It would be possible to notify all clients of a change in
non-client-specific PvD information by, for example, including a "pvd
generation number" in RAs.  The "ISP is captive portaling you because
you're infected" case can be handled by any such all-clients
notification scheme (e.g. pvd gen ids).  This is because the
architecture as described disconnects and reconnects the home network
and (I presume) every single device in the home is effectively and
equally captive.

But for individual clients, a push notification system for PvD state
changes is not yet immediately obvious to me.  For the specific case
of notifying captive state changes to clients I'm still hoping we can
use your ICMP portal notification option.