Erik Kline <[email protected]> wrote:
> If the document simply said that receiving and authenticating an ICMP
> message with the capport code generically "MAY/SHOULD trigger the
> receiving node's captive portal handling subsystem", would that be
> something that folks might agree on?
I think we can agree on it.
> We'll need to run this whole thing by intarea and 6man as well, of
> course.
> And nothing stops us from proposing a mulit-part extension to be
> optionally included in a future document, once the captive portal
> interaction recommendations are more fully understood.
True. We just can't make any of the extensions critical.
I think that's okay, since ignoring the ICMP is also acceptable.
> [ draft-larose-capport-architecture ]
> I felt it was promising to hear some agreement about the functional
> elements of a captive portal system as documented.
Please adopt it :-)
> Given that the captive portal interaction process is still on-going
> work, would the document authors think it worth trying to advance the
> document with either (a) section 3 removed or (b) section 3 rewritten
> to describe broadly how most clients behave today?
As a roadmap document, I have no problem with section 3 as is.
> Even given the
> variety of clients I think it could be roughly captured (e.g. make a
> few sacrificial queries to trigger DNS/HTTP rewrites, keep trying until
> a sacrificial query produces an expected result while launching an
> HTTP-capable application, and so on).
I think that this is something the WG should do after adoption.
I think that there is some IPv6 flow missing, specifically for the case where
no DHCPv6 occured (SLAAC-only). It could be that M=1 is mandatory for
captive portals.
Is there some reason we haven't adopted draft-nottingham-capport-problem-01 yet?
I would like the problem statement to outline the mechanisms used by current
captive portals and to give the mechanism names. e.g: DNS spoofing portal,
TCP-forced-proxy portal, etc.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature