Subject: Re: [Captive-portals] option 160 conflict

From: Tommy Pauly <[email-masked]>
Date: Thu, 02 Jan 2020 11:29:24 -0800

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) <[email-masked]> 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: [email-masked] <[email-masked]> 
> Sent: Monday, December 23, 2019 12:58 PM
> To: Lorenzo Colitti <lorenzo=[email-masked]>
> Cc: Bernie Volz (volz) <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]; Warren Kumari <[email-masked]>
> Subject: Re: [Captive-portals] option 160 conflict
>  
>  
> 
> 
> On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti <lorenzo=[email-masked] <mailto:lorenzo=[email-masked]>> wrote:
> 
> 
> On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <[email-masked] <mailto:[email-masked]>> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/captive-portals <https://www.ietf.org/mailman/listinfo/captive-portals>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 2 Jan 2020 17:32:16 -0500

> 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.…

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, [email-masked]
   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

> On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
>
> 
> On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <[email-masked]> wrote:
>
> [email-masked]
> 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

---

From: Erik Kline <[email-masked]>
Date: Thu, 2 Jan 2020 18:24:59 -0800

111 or 114 pending approval from Apple both seem fine to me.

I'll add an Appendix C with a brief summary of the 160 polycom experience
for posterity.

On Thu, 2 Jan 2020 at 14:33, Warren Kumari <[email-masked]> 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.
>
>
> > 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:
> >
> > 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
> >
> >
> > Cc: Bernie Volz (volz) <[email-masked]>; Michael Richardson <
> [email-masked]>; [email-masked]; Warren Kumari <
> [email-masked]>
> > 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
> >
> >

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Jan 2020 12:01:35 -0500

Warren Kumari <[email-masked]> wrote:
    >>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

I also like it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Adam Roach <[email-masked]>
Date: Fri, 3 Jan 2020 13:54:38 -0600

[as an individual]

I agree that this seems like an almost magically good solution to the 
conundrum that CAPPORT has, and strongly agree that this is the proper 
solution for this WG.

I am a bit sad that it doesn't scale to future DHCP options that other 
protocols may want to use.

/a

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 10 Jan 2020 09:19:02 -0800

> On Jan 2, 2020, at 6:24 PM, Erik Kline <[email-masked]> wrote:
> 

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?

Best,
Tommy

> 
> On Thu, 2 Jan 2020 at 14:33, Warren Kumari <[email-masked] <mailto:[email-masked]>> wrote:
> On Thu, Jan 2, 2020 at 2:29 PM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> >
>    Contact:           Dieter Siegmund, [email-masked] <mailto:[email-masked]>
> > On Dec 23, 2019, at 11:27 AM, Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi:
> >
> > From: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> > To: Lorenzo Colitti <lorenzo=[email-masked] <mailto:40google.com@dmarc..ietf.org>>
> > Cc: Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>>; Michael Richardson <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Warren Kumari <[email-masked] <mailto:[email-masked]>>
> > On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti <lorenzo=[email-masked] <mailto:[email-masked]>> wrote:
> >
> >

---

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Jan 2020 19:00:16 -0500

On Fri, Jan 10, 2020 at 12:19 PM Tommy Pauly <[email-masked]> wrote:
> As far as approval, I checked with Dieter who originally registered it,
and it's fine to use. So, Apple gives approval!
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, [email-masked] - 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

>> > OK, good to know. I had thought that there was support for using
option 160 in implementations as RFC7710 was published in December 2015.
>> > 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.
>> >
>> >
>> > 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 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

---

From: Erik Kline <[email-masked]>
Date: Fri, 10 Jan 2020 16:12:31 -0800

sounds good.  I'll patch that in and upload a -01.

On Fri, 10 Jan 2020 at 16:00, Warren Kumari <[email-masked]> wrote:

> >> > 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
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.
> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Jan 2020 21:26:50 -0800

-01 uploaded.

On Fri, Jan 10, 2020 at 4:12 PM Erik Kline <[email-masked]> wrote:

> sounds good.  I'll patch that in and upload a -01..
>
>> 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:
>> option 160 in implementations as RFC7710 was published in December 2015..
>> >> >
>> >> > 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
>> >> >
>> >> >
>> >> > 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.
>> >> >
>> >> >
>> >> > 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..
>> >> >
>> >> >