Regarding multiple IPv6 addresses, consider these two alternatives: 1. Associate the new address with an existing capport "session", for uninterrupted experience. 2. Treat a new address as a new session, for increased anonymity to the captive portal.
(I don't see how one can have the anonymity without the pain of signing in again.) Since the level of anonymity with the portal is dubious anyhow (it sees the MAC address, and possibly other credentials), and repeatedly signing into a portal is annoying, I think it is important to try to provide a standard for (1). Even if (1) is provided, the device of a privacy-seeking user could nonetheless choose to trigger the workflow of a new device, case (2). I propose that the capport API permits new IP addresses to be assigned to an existing session, by providing an appropriate token. -Dave -----Original Message----- From: Captive-portals [mailto:[email protected]] On Behalf Of Erik Kline Sent: Sunday, December 3, 2017 10:48 PM To: Michael Richardson Cc: Kyle Larose; [email protected] Subject: Re: [Captive-portals] IETF 100: ICMP Discussion Summary On 4 December 2017 at 09:25, Michael Richardson <[email protected]> wrote: > > {did not make it in person, and had a conflict and I haven't watched > the session on youtube yet} > > Kyle Larose <[email protected]> wrote: > > - Question was raised about whether we should restrict the number of v6 > > addresses (one address, one prefix, etc). > > Was there any consensus? > > I don't see a way to restrict the number of v6 addresses per UE except > via stateful DHCPv6, and few use that. No consensus yet, IIRC. <hats:off> My opinion is that we cannot restrict IPv6 addresses (violation of 7934). And any captive portal that identifies clients solely by IPv6 address is going to give some UEs a royally painful experience. When the downstream network architecture can include whole /64s given to single devices (e.g. 64-per-host) the experience will get really bad. This is just a reality of dealing with IPv6 (and I think it's a good thing). We just need to adapt, and I think it actually points to some constraints we can use to narrow down the solution space. As I see it at the moment, the only future-proof options come down do: - building into the portal/enforcement point knowledge of the network architecture - identifying clients by things that identify the device on-link (e.g. MAC address) - identifying clients by things that identify the link itself (DSL line ID, /64, ...) </hats> _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
