Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

[Michael Richardson <[e-mail]>]

Lorenzo Colitti <lorenzo=[e-mail]> wrote:
    > Is there a problem with saying that the portal server should identify the
    > device by IP address?

Tommy Pauly <tpauly=[e-mail]> wrote:
    > To that end, any enforcement of other traffic (such as normal web page
    > loading) will not be carrying any session identifier, so only signals
    > that are already present in the packets, such as the IP address, are
    > effectively useful here.

It's not obvious to me that you are talking about the same thing!
The portal server *could* use IP address as the key by which to identify
the device to the Captive Portal Enforcer.

That requires that the access to the Captive Portal Server to always
be on the same side of a NAT44 as the client, and I don't think that is
realistic given how these services are outsourced.

(In architecture-04, we have "Captive Portal Enforcement", which seems
to be an activity, while the description is about a thing.  So I think
that either the word "Point" should be added, or Enforcement->Enforcer)

The Captive Portal Enforcer SHOULD enable traffic based upon the mapped
L2 address, otherwise, there would have to be a new portal session for
IPv4 and IPv6, and for each new IPv6 temporary/privacy address.
I don't think we want that.  It would also, I think, force the portal
server to speak both v4 and v6.

The communication between Captive Portal Server and Captive Portal Enforcer
COULD identify the client by L3 address, but I wouldn't want to build things
that way, because it would result in a poor experience for returning users,
such as sleepy phones, or hotel guests that might leave the hotel and then
return later in the day, and expect their 24hr pass to just work, despite
DHCP leases being much shorter.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-