Re: [Captive-portals] option 160 conflict

Tommy Pauly <tpauly@apple.com> Thu, 02 January 2020 19:29 UTC

Return-Path: <tpauly@apple.com>
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 2AF39120128 for <captive-portals@ietfa.amsl.com>; Thu, 2 Jan 2020 11:29:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 NxJeNXpUC2YK for <captive-portals@ietfa.amsl.com>; Thu, 2 Jan 2020 11:29:35 -0800 (PST)
Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2FC1200D6 for <captive-portals@ietf.org>; Thu, 2 Jan 2020 11:29:35 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id 002JHRln044056; Thu, 2 Jan 2020 11:29:32 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=tmChAY9i3BvTK/z7Ln1KCcBf/qkiJei7/ytj1uGq+JQ=; b=dard9vKO1GvfMg6Ad4bEMezqpHqYERUxh927O62If6sXSrGYu6aYGzuWVKfcUq7VSXaS YdbtcKVViLq0fWa4xnzTiPvpTDk2ufGjPX9YPMj9OMfi0rSzPFkDaij2Pf5XuFY1Npp0 f4bZYlTztuvgUAT8At1lj4A+NMnSo2YidsatXvxBr+pDfDcaTGw/TpPR5O+AENtCYFpl yHnqoQB7vr3mHi9MJj9ghT4cwOo6RR3t38uDJPNJR3TuaonPC0exrUI8HbzyGo/0Ie96 WhVesKxHWWd7xa3KxlKGUgA5pig7CvSntzUKE+28JWUdjV//2MiK3OEtbefnxbXgw76Y OQ==
Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2x64gq2p4m-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 02 Jan 2020 11:29:32 -0800
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q3H00808VH74YC0@ma1-mtap-s01.corp.apple.com>; Thu, 02 Jan 2020 11:29:31 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q3H00800V0N8U00@nwk-mmpp-sz11.apple.com>; Thu, 02 Jan 2020 11:29:31 -0800 (PST)
X-Va-A:
X-Va-T-CD: 2f1456ce18e24ea32d298a17a960565e
X-Va-E-CD: ab4b98dd9665150474513f41f5c654ad
X-Va-R-CD: bc65fba3c5fd2e58404201a87315dfaf
X-Va-CD: 0
X-Va-ID: b4313011-79c5-4a97-8310-e33889350ad8
X-V-A:
X-V-T-CD: 2f1456ce18e24ea32d298a17a960565e
X-V-E-CD: ab4b98dd9665150474513f41f5c654ad
X-V-R-CD: bc65fba3c5fd2e58404201a87315dfaf
X-V-CD: 0
X-V-ID: cd3c61f0-c510-42c3-b322-edd67d591bb0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-02_06:,, signatures=0
Received: from [17.234.6.6] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q3H00IHXVH4S5B0@nwk-mmpp-sz11.apple.com>; Thu, 02 Jan 2020 11:29:29 -0800 (PST)
Sender: tpauly@apple.com
From: Tommy Pauly <tpauly@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_7B76EA03-C727-4639-9FCB-84FEFB36F001"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Date: Thu, 02 Jan 2020 11:29:24 -0800
References: <CAKD1Yr2yvqqw=APnyAb=gygR5KK6U7tcx3STGa9e6a8kJYO03w@mail.gmail.com> <150E4F32-236A-4D59-B74C-36BF523DCE55@apple.com> <DM6PR11MB413791A02517F481815C5353CF2E0@DM6PR11MB4137.namprd11.prod.outlook.com>
To: "Bernie Volz (volz)" <volz@cisco.com>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, "captive-portals@ietf.org" <captive-portals@ietf.org>, Warren Kumari <warren@kumari.net>
In-reply-to: <DM6PR11MB413791A02517F481815C5353CF2E0@DM6PR11MB4137.namprd11.prod.outlook.com>
Message-id: <8B5AF256-342B-4F7C-B5AE-6C3904DFB0DA@apple.com>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-02_06:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/TmqQz6Ma_fznD3XbhwkH9m2dB28>
Subject: Re: [Captive-portals] option 160 conflict
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 02 Jan 2020 19:29:38 -0000

One option we have is to use Code 114, which was reserved for use by Apple as a "URL" option. That particular codepoint wasn't ever used, so it should be open to be reclaimed as a CAPPORT API URL. Since this is in the range below 128, it should be safer to use.

Best,
Tommy

> On Dec 23, 2019, at 11:27 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> 
> Hi:
>  
> OK, good to know. I had thought that there was support for using option 160 in implementations as RFC7710 was published in December 2015.
>  
> I guess Warren will need to update the bis document to request IANA to assign a new DHCPv4 option (replacing 160) because of the potential conflict regarding its use – likely it would be useful to give some short justification for this (about the conflict). Likely the listing for option 160 will need to be something like:
>  
> 160         DEPRECATED (see new-option-code) - DHCP Captive-Portal           N             DHCP Captive-Portal       [RFC7710]
> 160         Polycom (vendor specific)
>  
> It may also be appropriate to request IANA assign 111 (if still available) as it has no reported use and is in the original (<128) IANA assigned space (as per RFC2132).
>  
> BTW: Code 115 (which was listed as used by failover in RFC3679) could also be a good choice as I am pretty sure it this was ever used (and if it was, it was for failover communication and not normal clients; and that use has long been deprecated).
>  
> Bernie
>  
> From: tpauly@apple.com <tpauly@apple.com> 
> Sent: Monday, December 23, 2019 12:58 PM
> To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>
> Cc: Bernie Volz (volz) <volz@cisco.com>om>; Michael Richardson <mcr+ietf@sandelman.ca>ca>; captive-portals@ietf.org; Warren Kumari <warren@kumari.net>
> Subject: Re: [Captive-portals] option 160 conflict
>  
>  
> 
> 
> On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org <mailto:lorenzo=40google.com@dmarc.ietf.org>> wrote:
> 
> 
> On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <volz@cisco.com <mailto:volz@cisco.com>> wrote:
> 1) It would not really remove the overlap for a long while (until all of the clients that used the "old" 160 Capport option are upgraded). So, devices will still need to deal with it for a long while.
>  
> Do any clients or networks actually implement 160 to mean capport? I know that iOS and Android, which seem most interested in this option, do not yet.
>  
> I am not aware of anything using the option yet. iOS does not use it; we used it for interop testing, but that is not in production code. 
> 
>  
> If they do not, the right thing to do would be to get a new option code, and do so as soon as possible so the implementations that are being written this year can immediately start using the new one.
>  
> I would also urge that if we want a new code, we allocate it soon so that the implementations can quickly test it out and ship the right value. 
>  
> Tommy
> 
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org <mailto:Captive-portals@ietf.org>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>