[Captive-portals] signaling no captive portal

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 03 March 2018 02:25 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179401270A3 for <captive-portals@ietfa.amsl.com>; Fri, 2 Mar 2018 18:25:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8O2yLSf2852 for <captive-portals@ietfa.amsl.com>; Fri, 2 Mar 2018 18:25:10 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D11512708C for <captive-portals@ietf.org>; Fri, 2 Mar 2018 18:25:10 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4CC4020091 for <captive-portals@ietf.org>; Fri, 2 Mar 2018 21:33:04 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 06ADD80BC4 for <captive-portals@ietf.org>; Fri, 2 Mar 2018 21:25:09 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: captive-portals@ietf.org
In-Reply-To: <CAHw9_iKmj_CYNwm+i6ETKF3FSVwEp-NGVfiMfPiBE3QCUbKzkQ@mail.gmail.com>
References: <CABkgnnWJMipRtG-p0EoUXmK3u1c2ab-v4xN3WZfm3XL8s08aZA@mail.gmail.com> <CAHw9_iKmj_CYNwm+i6ETKF3FSVwEp-NGVfiMfPiBE3QCUbKzkQ@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 02 Mar 2018 21:25:08 -0500
Message-ID: <23941.1520043908@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/PTUsrJu69ep1iu1r4nG4DRkom2M>
Subject: [Captive-portals] signaling no captive portal
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Mar 2018 02:25:12 -0000

Warren Kumari <warren@kumari.net> wrote:
    >> 2. There isn't a clear way to signal that there is no captive portal
    >> in the network.  It has been suggested that we use a special URL -
    >> e.g., urn:ietf:params:capport:unrestricted. Alternatively, we could
    >> privilege the empty string, but that doesn't have as clear a signal of
    >> intent.

    > Oooh, I like the special URL idea -- initially the thought was a
    > combination of:

    > 1: Until this is ubiquitously deployed (ha!), devices will need to do
    > CP heuristics, and so will discover the lack of CP through that.
    > 2: If there is no CP, no-one is likely to include the option.
    > 3: Since the vast majority of networks don't use CPs, is this an undue
    > burden on them?

In the case where there *was* a captive portal on a network, and now there is
not, it might be useful to tell clients that life has changed.  The client
might prefer to stay on 3G or pick another network rather than try that
portal.

It might also be meaningful to signal no-captive portal to clients which
have previously connected, but will no longer be challenged (ever? until DHCP
lease timeout?).  For instance, if I whitelist your laptop MAC address in my
home.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-