Re: [Captive-portals] option 160 conflict
Warren Kumari <warren@kumari.net> Sat, 11 January 2020 00:00 UTC
Return-Path: <warren@kumari.net>
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 4F57D120047 for <captive-portals@ietfa.amsl.com>; Fri, 10 Jan 2020 16:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 hhGMOGaa1mMe for <captive-portals@ietfa.amsl.com>; Fri, 10 Jan 2020 16:00:29 -0800 (PST)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC9612012D for <captive-portals@ietf.org>; Fri, 10 Jan 2020 16:00:28 -0800 (PST)
Received: by mail-qv1-xf2b.google.com with SMTP id n8so1607924qvg.11 for <captive-portals@ietf.org>; Fri, 10 Jan 2020 16:00:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TKxhpf6xw3XyhsIYoeQkvZPi3OHc2wEq6wGUy7C6SHg=; b=C0Q5Lb6Gi2PuHeOQwNue+KFAfQrWbHqm0f3tPNpsdN/5HN/zXuHzGLkA+vY8/x1UxE DoIYoHwE9SVonFTkSPm89c1A9D3EACtmc+IJssPHmog7lijQTJM8XZCa/dA9WRC4u0K5 pxXXRjZOJoxQiGlnT4rcuXPE5DH4WwhyhbL8wgGNaZst7UnLfCFrHnlA5gu0gh4yG7Iz cr2oFlVqiHhHY+9IUMsUybPpyAD3ntG/+all/5pK3W0a5gVxf39QmFJFoHI1RqS60P6J k91tEO/c5oaAfONdCZtlJAcNKuHLXQrT7IGRZ9NwaM4LILiLHIbq0oa+qJfFe+/xvzvw mM6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TKxhpf6xw3XyhsIYoeQkvZPi3OHc2wEq6wGUy7C6SHg=; b=H0LtDymIfLHIKsmPYp3qi+pfFLBqXLUjVp3npg7ZW8rBOwSgYs2hhRiMwlJPdyvTOT R318SQt3/FH5/OW9AYVfNTM4wzb8EoyZTQM3NagHctcoj/4teIMfBg3XmnxjQHiJpyH3 oKH4f9MpxsbKegYaPosehfv+GQ3JC2oTY6hdYZkLDJelvMXmhrQ3vfKZ04nC7pZj88OB g+OdHivtK3HZwrs/fTbPTtKzbGzgJfZCybzSzs/40TlPKiZ5PpqwWpl44FrUjeu8r4Ez 9KcElI/QUv04Mc49WlHH1PxOPwqyQ6Et4Wqli68u513V4JoAVFJBjB6FY5xpZzaDQ+JQ QeGg==
X-Gm-Message-State: APjAAAVxHiAuXKNNM0+1yjDJZE9qup5C7L7VtB17WSI3iIMgf++2WhxY d7MLBUN0wDkg2zleY4iAvpfq/QJG4v1ocga3CJuvQg==
X-Google-Smtp-Source: APXvYqw+7jKD4h+9CNCnGkkA/t5+MfM439VvGR7oWALZ8vhFtltEw4Z+scB7giBdzkbI9XcPVttJzchLNcAT17Dze4E=
X-Received: by 2002:a0c:d788:: with SMTP id z8mr1132702qvi.211.1578700827466; Fri, 10 Jan 2020 16:00:27 -0800 (PST)
MIME-Version: 1.0
References: <CAKD1Yr2yvqqw=APnyAb=gygR5KK6U7tcx3STGa9e6a8kJYO03w@mail.gmail.com> <150E4F32-236A-4D59-B74C-36BF523DCE55@apple.com> <DM6PR11MB413791A02517F481815C5353CF2E0@DM6PR11MB4137.namprd11.prod.outlook.com> <8B5AF256-342B-4F7C-B5AE-6C3904DFB0DA@apple.com> <CAHw9_iJrtGY=qUFngb=epJuLxrwfryv5peD=wx=2GL-ScV3kFw@mail.gmail.com> <CAAedzxqhtYUv9hX8FqnnGT6T22Oa4=pSx_BFgyhxK-mQw9VDig@mail.gmail.com> <67A25A2A-04FF-4A1D-B0B5-F0CE14E15FC0@apple.com>
In-Reply-To: <67A25A2A-04FF-4A1D-B0B5-F0CE14E15FC0@apple.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 10 Jan 2020 19:00:16 -0500
Message-ID: <CAHw9_iK_wv_qSj7sKV8c2aF8VjEz4JuEQBjGE2w2qNK4DZA2VA@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>
Cc: "Bernie Volz (volz)" <volz@cisco.com>, Erik Kline <ek@loon.com>, Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000007326d059bd1eec4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/7eSQA-4r9V1bVdEBJXgfEiKRUAU>
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: Sat, 11 Jan 2020 00:00:32 -0000
On Fri, Jan 10, 2020 at 12:19 PM Tommy Pauly <tpauly@apple.com> wrote: > > > > On Jan 2, 2020, at 6:24 PM, Erik Kline <ek@loon.com> wrote: > > 111 or 114 pending approval from Apple both seem fine to me. > > > As far as approval, I checked with Dieter who originally registered it, and it's fine to use. So, Apple gives approval! > > > I'll add an Appendix C with a brief summary of the 160 polycom experience for posterity. > > > Sounds good. And do we just need to update the IANA Considerations to ask for 114? Yup. I'd think that adding something like the below to the IANA Considerations section would work: [RFC Ed: Please remove before publication: RFC7710 uses DHCP Code 160 -- unfortunately, it was discovered that this option code is already widely used by Polycom (see Appendix C). Option 114 (URL) is currently assigned to Apple (RFC3679, Section 3.2.3 - Contact: Dieter Siegmund, dieter@apple.com - Reason to recover: Never published in an RFC) Tommy Pauly (Apple) and Dieter Siegmund confirm that this codepoint hasn't been used, and Apple would like to relinquish it for use in CAPPORT. Please see thread: https://mailarchive.ietf.org/arch/msg/captive-portals/TmqQz6Ma_fznD3XbhwkH9m2dB28 for more background ] The IANA is requested to update the "BOOTP Vendor Extensions and DHCP Options" registry ( https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml) to: Tag: 114 Name: DHCP Captive-Portal Length: N Meaning: DHCP Captive-Portal Reference: [THIS-RFC] Tag: 160 Name: REMOVED/Unassigned Length: Meaning: Reference: [RFC7710][Deprecated]. —— Seeing as this is an unusual case, I’ll ask the IANA / Michele nicely how this should best be worded / explain the background / ask nicely... W > > Best, > Tommy > > > On Thu, 2 Jan 2020 at 14:33, Warren Kumari <warren@kumari.net> wrote: >> >> On Thu, Jan 2, 2020 at 2:29 PM Tommy Pauly <tpauly@apple.com> wrote: >> > >> > 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. >> >> >> I *really* like this idea - the options even contains something that >> looks like a URL :-) >> >> Is there any reason *not* to reuse this? There is a note in RFC 3679 >> (Unused DHCP Option Codes) saying: >> >> Code: 114 >> Name: URL >> Defined in: (none) >> Contact: Dieter Siegmund, dieter@apple.com >> Reason to recover: Never published in an RFC >> >> If this does get resulted for CAPPORT, should we file a Hold For >> Document Update errata noting that this is no longer true? >> >> Thank you Tommy! >> W >> >> >> > >> > 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>; Michael Richardson < mcr+ietf@sandelman.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> wrote: >> > >> > >> > On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <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 >> > https://www.ietf.org/mailman/listinfo/captive-portals >> > >> > >> >> >> -- >> 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 > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > -- 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 -- 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] option 160 conflict Michael Richardson
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Bernie Volz (volz)
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Bernie Volz (volz)
- Re: [Captive-portals] option 160 conflict Michael Richardson
- Re: [Captive-portals] option 160 conflict Lorenzo Colitti
- Re: [Captive-portals] option 160 conflict Tommy Pauly
- Re: [Captive-portals] option 160 conflict Bernie Volz (volz)
- Re: [Captive-portals] option 160 conflict Tommy Pauly
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Erik Kline
- Re: [Captive-portals] option 160 conflict Michael Richardson
- Re: [Captive-portals] option 160 conflict Adam Roach
- Re: [Captive-portals] option 160 conflict Tommy Pauly
- Re: [Captive-portals] option 160 conflict Warren Kumari
- Re: [Captive-portals] option 160 conflict Erik Kline
- Re: [Captive-portals] option 160 conflict Erik Kline