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

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Dec 2019 21:53:24 -0500

On Thu, Nov 28, 2019 at 2:56 AM Michael Richardson
<[email-masked]> wrote:
>
>
> Bernie Volz (volz) <[email-masked]> wrote:
>     > The issue with the 128-254 option range is that they were, originally,
>     > site-specific options (i.e., available for use within a site). However,
>     > many vendors hijacked them. And, when we reassigned much of this range
>     > to the IANA assigned options pool, the vendors failed to request a more
>     > permanent assignment for their option use. I suspect though that you
>     > are well aware of that entire process
>     > (https://tools.ietf.org/html/rfc3942).
>
>     > I don't know when Polycom decided to use this 160 option as RFC3942
>     > dates back to November 2004.
>
> This explains a lot about why we conflicted on option 160, and that perhaps
> we shouldn't have been so upset.
>

Reviving an old thread -- I was one of the people a: who was
super-annoyed by this and b: helping run the CAPPORT experiment at
IETF106, where we discovered the issue.

Having had some time to reflect on this, and with the history lesson
from Bernie, I am leaning towards the "Meh, we should just stick with
Option 160" stance...

We *could* ask for a new one in the -bis, and I suspect that e.g 169
won't be as "polluted", but I might be wrong, and it might be as bad
or worse....

Here is a random PDF of known usages -
https://link.springer.com/content/pdf/bbm%3A978-1-4302-2773-1%2F1.pdf
-- does anyone have a more complete list?

W

> It seems to me that DHC WG has to help IANA avoid conflicts like this in the
> future.
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [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: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 20 Dec 2019 15:44:54 +0000

I think the list at https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml is more complete and it is the "authoritative" list?

The only entry at the link you provided that doesn't seem to be in the IANA page is 252, but that is in the "Reserved (Private Use)" range so would not conflict (with IANA assignments, though could if privately used for multiple purposes). But, it is possible I missed something.

Note also that the IANA page lists the multiple uses, if we were notified that there are several uses of an option code.

Also, if you have details on what else option 160 is used for (a bit more than just "Polycom"), it would be useful to know as I can request IANA to add that usage to the table - just so people are aware that there could be issues in the field.

While I don't think it makes sense to change the option code in a published RFC (as that likely would create even more confusion), if you did, codes <128 are "safer" as they were always in the range that was managed by IANA (however, that did not prevent someone from using without going through IETF processes).

- Bernie

-----Original Message-----
From: Warren Kumari <[email-masked]> 
Sent: Thursday, December 19, 2019 9:53 PM
To: Michael Richardson <[email-masked]>; Bernie Volz (volz) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Captive-portals] option 160 conflict

On Thu, Nov 28, 2019 at 2:56 AM Michael Richardson <[email-masked]> wrote:
> This explains a lot about why we conflicted on option 160, and that 
> perhaps we shouldn't have been so upset.
>

Reviving an old thread -- I was one of the people a: who was super-annoyed by this and b: helping run the CAPPORT experiment at IETF106, where we discovered the issue.

Having had some time to reflect on this, and with the history lesson from Bernie, I am leaning towards the "Meh, we should just stick with Option 160" stance...

We *could* ask for a new one in the -bis, and I suspect that e.g 169 won't be as "polluted", but I might be wrong, and it might be as bad or worse....

W

> It seems to me that DHC WG has to help IANA avoid conflicts like this 
> in the future.
>
> --

--
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: Warren Kumari <[email-masked]>
Date: Fri, 20 Dec 2019 12:51:47 -0500

> I think the list at https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml is more complete and it is the "authoritative" list?

Ah, yes, that is (clearly) the authoritative source, but what I didn't
realize (honestly, because I didn't look :-)) was that it also
included known unauthorized uses.

> The only entry at the link you provided that doesn't seem to be in the IANA page is 252, but that is in the "Reserved (Private Use)" range so would not conflict (with IANA assignments, though could…

Nope, you didn't miss anything - I got over-excited finding that list,
and didn't bother checking the IANA list...

> Also, if you have details on what else option 160 is used for (a bit more than just "Polycom"), it would be useful to know as I can request IANA to add that usage to the table - just so people are…

Will do - Singapore is all a bit of a blur at this point, but
apparently Polycom started using 160 "in order to avoid issues in
environments where option 66 was already used by other VoIP phones
from different manufacturers.", and also "LYNC SKU Polycom VVX phone
it will use Option 161 instead to ensure a mix of phones can be used."
(https://community.polycom.com/t5/VoIP-SIP-Phones/DHCP-Standardization-160-vs-66/td-p/72577
- Standardization: "You Keep Using That Word, I Do Not Think It Means
What You Think It Means") -- this is all clearly somewhat of a mess,
and will need more research, but apparently the option contains a URI
for fetching provisioning info, which contains stuff like if the phone
should auto-answer, etc...

> While I don't think it makes sense to change the option code in a published RFC (as that likely would create even more confusion), if you did, codes <128 are "safer" as they were always in the rang…

Yup - we have RFC7710, which uses Option 160. We are currently working
on / almost done with RFC7710bis (
https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ )
which fixes (and obsoletes) some stupidity in RFC7710 -- we were
considering asking for a new code when draft-ietf-capport-rfc7710bis
is published (so this would be part of a new document, not withdrawing
and republishing just for this issue).
I've helped run a number of conference networks (one of the uses for
RFC7710 / draft-ietf-capport-rfc7710bis), and have often seen
Polycom's in use - as "nah, you can't use your conference phone at our
conference" is likely not a tenable position, do you think we should
request that we get a <128 option when we publish
draft-ietf-capport-rfc7710bis ?

W

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 20 Dec 2019 22:53:25 +0000

Hi:

To me with just a quick glance at the bis document, it seems that the option format has not changed and still contains the same information.

I don't really know what pain there has been with the 160 conflict (in terms of what interoperability issues it has created, etc.) so it is difficult for me to judge whether asking for a new option code is worth it or not. 

I see that:
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.
2) It creates additional problems as new clients likely need to request both and prefer the new one over the old 160. As it could also be a while until servers in the field are upgraded (software and configuration). And, since this URI might be long, servers without special handling would return both which could cause MTU issues. (See below *).
3) When, if ever, could you stop supporting the old option? I guess a server operator could take a survey, but if there are these phones around, they may still request it and would the operator be able to tell the difference?

Certainly you would not need a new one for v6!

I would also suggest looking to see if there is a way for servers to potentially distinguish whether the device asking is a Polycom option vs a Capport option - at least then you could add text that suggests servers might want to solve this problem by having a way to distinguish the two options to send the correct one. For example, many devices will send a class id option (60) to identify the device class and this could potentially be used.

Finally, it would good if Polycom moved away from using option 160 - perhaps by moving to a Vendor-Identifying option (see RFC3925). But that also has the same issues as mentioned above since probably both the old and new vendor identifying would have to be used -- but that also helps in servers determining whether it is a Polycom device or not asking for option 160.

Sadly, there's no really great solution to this issue. We did push to request those that hijacked options to report them, but we obviously didn't reach everyone and perhaps this also is much more recent than that earlier work.

* (From see below above) - One solution might be to use the new option code just to signal to the server that "hey, the 160 option I was asking for is the Capport Option". Kind of an odd way of doing it, but avoids the issue of bloating the response packets from the server. For support, it requires special processing on the server. In any case, you might want to raise this to the DHC WG as perhaps others may have some suggestions as to how best to handle this.

- Bernie

-----Original Message-----
From: Warren Kumari <[email-masked]> 
Sent: Friday, December 20, 2019 12:52 PM
To: Bernie Volz (volz) <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Captive-portals] option 160 conflict

> I think the list at https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml is more complete and it is the "authoritative" list?

Ah, yes, that is (clearly) the authoritative source, but what I didn't realize (honestly, because I didn't look :-)) was that it also included known unauthorized uses.

> The only entry at the link you provided that doesn't seem to be in the IANA page is 252, but that is in the "Reserved (Private Use)" range so would not conflict (with IANA assignments, though could…

Nope, you didn't miss anything - I got over-excited finding that list, and didn't bother checking the IANA list...

> Also, if you have details on what else option 160 is used for (a bit more than just "Polycom"), it would be useful to know as I can request IANA to add that usage to the table - just so people are…

Will do - Singapore is all a bit of a blur at this point, but apparently Polycom started using 160 "in order to avoid issues in environments where option 66 was already used by other VoIP phones from different manufacturers.", and also "LYNC SKU Polycom VVX phone it will use Option 161 instead to ensure a mix of phones can be used."
(https://community.polycom.com/t5/VoIP-SIP-Phones/DHCP-Standardization-160-vs-66/td-p/72577
- Standardization: "You Keep Using That Word, I Do Not Think It Means What You Think It Means") -- this is all clearly somewhat of a mess, and will need more research, but apparently the option contains a URI for fetching provisioning info, which contains stuff like if the phone should auto-answer, etc...

> While I don't think it makes sense to change the option code in a published RFC (as that likely would create even more confusion), if you did, codes <128 are "safer" as they were always in the rang…

Yup - we have RFC7710, which uses Option 160. We are currently working on / almost done with RFC7710bis ( https://datatracker.ietf.org/doc/draft-ietf-capport-rfc7710bis/ ) which fixes (and obsoletes) some stupidity in RFC7710 -- we were considering asking for a new code when draft-ietf-capport-rfc7710bis is published (so this would be part of a new document, not withdrawing and republishing just for this issue).
I've helped run a number of conference networks (one of the uses for
RFC7710 / draft-ietf-capport-rfc7710bis), and have often seen Polycom's in use - as "nah, you can't use your conference phone at our conference" is likely not a tenable position, do you think we should request that we get a <128 option when we publish draft-ietf-capport-rfc7710bis ?

W

> > It seems to me that DHC WG has to help IANA avoid conflicts like 
> > this in the future.
> >
> > --

---

From: Michael Richardson <[email-masked]>
Date: Sat, 21 Dec 2019 17:52:42 -0500

Bernie Volz (volz) <[email-masked]> wrote:
    > I see that: 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 think that this is a single upgrade cycle for some smartphone OSs.
I think that could occur faster than the RFC-editor queue will process the
document actually.

    > 2) It creates additional problems as new clients likely need to
    > request both and prefer the new one over the old 160. As it could also
    > be a while until servers in the field are upgraded (software and
    > configuration). And, since this URI might be long, servers without
    > special handling would return both which could cause MTU issues. (See
    > below *).

    > 3) When, if ever, could you stop supporting the old option?
    > I guess a server operator could take a survey, but if there are these
    > phones around, they may still request it and would the operator be able
    > to tell the difference?

I think that there are few production server systems out there to worry
about.   I think that the people involved are on this list.
I think that we could switch very quickly.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 22 Dec 2019 12:48:28 +0900

On Sat, 21 Dec 2019, 07:53 Bernie Volz (volz), <[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.

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.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 23 Dec 2019 09:58:08 -0800

> On Dec 21, 2019, at 7:48 PM, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> 
> 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: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 23 Dec 2019 19:27:41 +0000

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.

Tommy

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals