Re: [Captive-portals] option 160 conflict

On Fri, Dec 20, 2019 at 10:44 AM Bernie Volz (volz) <volz@cisco.com> wrote:
>
> 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 if privately used for multiple purposes). But, it is possible I missed something.

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

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

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 range that was managed by IANA (however, that did not prevent someone from using without going through IETF processes).

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

>
> - Bernie
>
> -----Original Message-----
> From: Warren Kumari <warren@kumari.net>
> Sent: Thursday, December 19, 2019 9:53 PM
> To: Michael Richardson <mcr+ietf@sandelman.ca>; Bernie Volz (volz) <volz@cisco.com>
> Cc: captive-portals@ietf.org
> Subject: Re: [Captive-portals] option 160 conflict
>
> On Thu, Nov 28, 2019 at 2:56 AM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> >
> >
> > Bernie Volz (volz) <volz@cisco.com> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> > _______________________________________________
> > 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