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>om>; Michael Richardson <
mcr+ietf@sandelman.ca>gt;; 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