Re: [Captive-portals] option 160 conflict

["Bernie Volz (volz)" <[e-mail]>]

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 <[e-mail]> 
Sent: Friday, December 20, 2019 12:52 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: Michael Richardson <[e-mail]>; [e-mail]
Subject: Re: [Captive-portals] option 160 conflict

On Fri, Dec 20, 2019 at 10:44 AM Bernie Volz (volz) <[e-mail]> 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 <[e-mail]>
> Sent: Thursday, December 19, 2019 9:53 PM
> To: Michael Richardson <[e-mail]>; Bernie Volz (volz) 
> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Captive-portals] option 160 conflict
>
> On Thu, Nov 28, 2019 at 2:56 AM Michael Richardson <[e-mail]> wrote:
> >
> >
> > Bernie Volz (volz) <[e-mail]> 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 <[e-mail]>, Sandelman Software Works 
> > -= IPv6 IoT consulting =-
> >
> >
> >
> > _______________________________________________
> > Captive-portals mailing list
> > [e-mail]
> > 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