Subject: [Captive-portals] DHCP/Captive Portal Experiment at IETF106 - SIN

From: Christopher Morrow <[email-masked]>
Date: Sat, 16 Nov 2019 17:09:03 +0800

Howdy!

During setup at the IETF meeting this week in Singapore the noc folk
setup an experiment on the IETF wireless network, specifically on the
IETF SSID to test your shiny new DHCP option(s) for captive portal,
information about that is detailed here:
  https://tickets.meeting.ietf.org/wiki/CAPPORT

So far, during our setup we noticed Polycom conference phones are
'unhappy' with this DHCP option (over ipv4). The Polycoms appear to
believe that option 160 is for 'boot file location' :( Ingesting a
json file for booting makes the Polycom sad :(

-chris

fyi:
There is a polycom community discussion about their behavior here:
  https://community.polycom.com/t5/VoIP-SIP-Phones/DHCP-Standardization-160-vs-66/m-p/72579/highlight/true#M13020

---

From: Michael Richardson <[email-masked]>
Date: Sun, 17 Nov 2019 11:03:26 +0800

> believe that option 160 is for 'boot file location' :( Ingesting a json
    > file for booting makes the Polycom sad :(

So, did they squat on this option, and should CAPPORT ask for a new number?

---

From: Erik Kline <[email-masked]>
Date: Sun, 17 Nov 2019 13:27:15 +0900

On Sun, 17 Nov 2019 at 12:03, Michael Richardson <[email-masked]> wrote:

> json

Some of the comments in that thread seem very disappointing and aggravating
even (saying they'll use 161 if they need to, for example, which is
allocated for MUD).

We could ask for a new option, or we could decide that it's not a big
enough problem in the real world.  I've added this to a slide for
discussion on Wednesday morning.

<no hats> I think my first inclination would be to speculate wildly and
without data about whether the anticipated intersection of Polycom and
captive portal networks is big enough to worry about.  I mean, technically,
they're "holding it wrong"...

---

From: Warren Kumari <[email-masked]>
Date: Sun, 17 Nov 2019 12:38:42 +0800

> So, did they squat on this option, and should CAPPORT ask for a new number?

So, I had a very brief chat with IANA about this - because the assignment
is in an RFC, changing it will be hard - it would require deprecating
RFC7710, and publishing a new one with just the port changed...

Seeing as RFC7719bis is almost done (hopefully!) it seem to me that it
would make more sense to just ask for a new port in that.

What would be interesting would be to try figure out if the next few codes
(162 - 174) are “clean”.

E.g: Wyze seems to squat on 162, 163 is
“Cisco-client-last-transaction-time” (?), etc.

The current conflict with Polycom seems really bad (People having remote
meetings often travel with polycoms). We really shouldn’t let
squatters-rights drive our decisions, and I don’t think that conflicts with
others will be as bad....

W

>
>
> _______________________________________________
> 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: Michael Richardson <[email-masked]>
Date: Mon, 18 Nov 2019 10:06:02 +0800

Warren Kumari <[email-masked]> wrote:
    >> Christopher Morrow <[email-masked]> wrote: > During
    >> setup at the IETF meeting this week in Singapore the noc folk > setup
    >> an experiment on the IETF wireless network, specifically on the > IETF
    >> SSID to test your shiny new DHCP option(s) for captive portal, >
    >> information about that is detailed here: >
    >> > So far, during our setup we noticed Polycom conference phones are >
    >> 'unhappy' with this DHCP option (over ipv4). The Polycoms appear to >
    >> json > file for booting makes the Polycom sad :(
    >> 

    > So, I had a very brief chat with IANA about this - because the
    > assignment is in an RFC, changing it will be hard - it would require
    > deprecating RFC7710, and publishing a new one with just the port
    > changed...

Oh, yes.. I forgot that it was in the RFC not the new ID.

    > would make more sense to just ask for a new port in that.

I think that we can do that. 
Unless the result is that polycom devices brick, in which case, I think we
should stick with 160, and Polycom can deal with being bad netizens.

    > What would be interesting would be to try figure out if the next few
    > codes (162 - 174) are “clean”.

Yes, I agree that we need to do that, and to recycle 160 to the end of the
list to be marked as unused and to be allocated at the end.

I'm so glad we discovered this now.

    > The current conflict with Polycom seems really bad (People having
    > remote meetings often travel with polycoms). We really shouldn’t let
    > squatters-rights drive our decisions, and I don’t think that conflicts
    > with others will be as bad....

Warren,
I'd like to ask the IAB Program that produced draft-iab-protocol-maintenance
to consider some set of processes for squatters.  (Squatters are tolerated by
by being liberal in what you accept)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Nov 2019 10:09:55 +0800

Erik Kline <[email-masked]> wrote:
    > Some of the comments in that thread seem very disappointing and
    > aggravating even (saying they'll use 161 if they need to, for example,
    > which is allocated for MUD).

DHCP options are not hard to get.
Polycom should know better.