Re: [dhcwg] DHCP Options for Network-Assisted Multipath TCP (MPTCP)

[Simon Hobson <[e-mail]>]

[e-mail] wrote:

> Wouldn't be better to fix the broken client implementation?  

Yes, in the general case that would be the correct response. But I think few of us have never found themselves in a situation where something is "not quite right" but the vendor shrugs their shoulders and takes the attitude "it works for us".
It's one thing for an open source client where even if the original authors/maintainers don't care, it's possible for someone else to pick it up and deal with it. It's a different matter if it's some proprietary piece of junk someone's just put on the network and expects the admin to make it work.

> Relaxing the behavior at the server side leads to another question: how to ensure that a broken client will correctly interpreted an option it didn't ask for? 

It may be a simple issue of the client author just not having configured the client to ask for it - perhaps being one of those that only ever tests with their own server that they've configured to always send it. That's the other situation I've seen - "client" devices built on the assumption that the only network they'll ever be connected to is managed by the same vendor's "server" device. Any suggestion to the vendor that there's a problem is met with a "it works with our ${box of tricks}" so it must be your server that's at fault - so the only way to work round it is to "misconfigure" your own server to match the broken vendor server.