Hi all,
----
For non-CAPPORT regulars:
Don't panic -- we are not planning on actually having a Captive
Portal; this advertises to CAPPORT compatible clients that there is no
captive portal on the network ("captive": false), and an informational
URL ("venue-info-url": "https://ietf.org/experiment/capport";) which
clients can go to if they'd like some information about the location.
----
Barring any unforeseen issues the IETF network in Singapore will be
hosting a draft-ietf-capport-rfc7710bis style CAPPORT experiment.
The DHCP servers will be serving the Captive-Portal DHCPv4 (160) and
The Captive-Portal DHCPv6 (103) options. These options will contain a
CAPPORT API URL which answers with:
HTTP/1.1 200 OK
Cache-Control: private
Date: <...>
Content-Type: application/captive+json
{
"captive": false,
"venue-info-url": "https://ietf.org/experiment/capport";
}
We may also be able to advertise this using the IPv6 RA solution, but
this is technically trickier[0].
As this is an experiment, it is low down on the NOC priority list
(building the network comes first), and can be terminated at any time.
(Note: I'm wearing both author and NOC participant hats)
Warren.
---
[0]: The routers for the IETF meeting venue networks are Junipers, and they:
a: don't seem to support RFC7710 yet and
b: don't seem to allow for arbitrary RA information to be stuffed in.
The NOC is investigating if we can use other routers (Ubiquiti) to
inject RAs with this info.
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
