Regarding DHCP, I think we have to assume the rfc 7710 attribute remains in the responses always. Not all capport implementations use an integrated DHCP server, and I don't think DHCP should be queried by clients for capport state.
I think a hybrid approach, ICMP/API, would be efficient . One scenario I see frequently isUser connects to access point 1 and has internetUser starts an internet sessionUser moves closer to access point 2(different network w/ captive portal) automatically connects due to RSSIsUser sends packets as if the device has internetMany devices won't even re-IP or send a DHCP discover even though are on a different network completely. The ICMP response for these packets could trigger the captive portal faster for a better user experience.For the DHCP option from RFC7710, is it correct to say a device should not assume the device is behind a captive portal based on that option being present in the DHCP offer? If the option stays after authentication, the device can still receive that URL if it were used as an API endpoint. Then ICMP could be the mechanism for state.On Wed, Aug 31, 2016 at 9:28 AM, David Bird <[email protected]> wrote:
I am working updating https://tools.ietf.org/html/dr
aft-wkumari-capport-icmp-unrea. I plan to add a 'policy class' uint32 to the ICMP message that can be used as a site specific 'hint' to the captive portal. This uint32 is site specific and -can- be unique per visitor and should only be used by portal as a hint/reason (capport URL gotten from DHCP rfc 7710) . ch-01On Aug 31, 2016 5:55 AM, "Dave Dolson" <[email protected]> wrote:An ICMP extension could notify a sender that a 5-tuple connection is walled off. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).This will be more real-time than relying on the sender to periodically probe well-known servers on port 80.
Such a message should indicate a reason, which could be a URL to a JSON/REST interface.
Or, it could simply be an event that means "go probe port 80 to get redirected"
I believe ICMP is useful for realtime, 5-tuple flow specific (as well as general), notifications, but it should not be used to carry any session parameters or meaningful data. A REST API would be better for that.
On Tue, Aug 30, 2016 at 2:49 PM, Alexander Roscoe <[email protected]> wrote:
I am looking at the mechanisms to communicate captive portal states to
users. I think a RESTful API would be viable candidate for
communicating this information. The same URL from RFC7710 or the URL
given by the 302 redirect could be used to as the endpoint for this
service as well. Clients could reach out to this endpoint to get
status such as "Time Remaining" or "TX/RX transferred". RESTful
interfaces can be easily setup and can be easily extended to add new
Along side REST, I was looking at the ICMP as a conduit to transmit
this information as well. Information could be pushed to the clients'
device and then digested rather than pulled like a RESTful protocol.
I think an implementation of this setup could work well on a
deployment where the AAA server resides on the same system as the
gateway because the information in the ICMP is easily accessible.
When the AAA server exists on another system it may pose a problem.
For example, many networks that use captive portals block external
ICMP messages and/or NAT devices to client, therefore the gateway
would need to proxy these packets. This adds more complexity to the
network design. Also, ICMP message would be very rigid and not as
extendable as a RESTful service. Maybe rigid might be a good thing?
Thoughts? Did I miss another type of conduit to transfer status...
excluding SOAP :)
Captive-portals mailing list