Hello,
Please allow me a comment on this RFC.
During my recent travel I encountered two hotspots which re-direct to
"controller.access.network" FQDN in the URL bar of the browser.
It looked to me as a 'standardized' FQDN since the domain .network does
not exist AFAIK, and since this was on two different hotspots (hotel and
airport). Is access.network a standardized domain? (I am thinking of a
test domain or so).
If so then that might be the content of this DHCP/RA option proposed in
the RFC?
Alex
Le 30/09/2015 03:32, The IESG a écrit :
The IESG has approved the following document:
- 'Captive-Portal Identification in DHCP / RA'
(draft-wkumari-dhc-capport-16.txt) as Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Joel Jaeggli.
A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/
Technical Summary
This document describes a DHCP option and an RA extension to inform
nodes that they are behind some sort of captive portal device, and
that they will need to authenticate to get Internet Access.
Working Group Summary
This document was reviewed by the DHC working group, but was not adopted
there because the work is not in charter. Because it defines new DHCP options,
it's not really in charter for 6man either. Taken forward as an AD sponsored
it has had abundant review. been the inspiration for a BOF and generally
received positive attention.
Document Quality
Dan L??dtke has done an implementation of the router side of the RA option.
We are aware of no RA listener implementations nor DHCP client
implementations. Because this document defines DHCP options,
any generally-configurable DHCP server or client can
readily be configured to support this new option, typically without recompilation.
The option question for this document is whether captive portal manufacturers
and, more importantly, DHCP client implementors and RA listener implementors
will see the extension as valuable and make use of it.
The reason for advancing it at this stage rather than waiting for widespread
adoption is that until a standard format is defined, the extension serves no
useful purpose and cannot be deployed. By documenting this extension,
we hope to provide an opportunity for improvement in the way captive
portals are operated.
Personnel
Ted Lemon is the document shepherd.
Joel Jaeggli is the responsible AD.