On 31 August 2017 at 22:04, David Bird <[email protected]> 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.
Description: S/MIME Cryptographic Signature