Hello Theo, It's disheartening to see the disparity in treatment between entities like OpenBSD and larger corporations within these governance structures. However, your resolve in the face of such challenges is commendable. The creation of CARP, under the circumstances you described, not only serves as a practical solution but also as a principled stand against the monopolization of technology standards. This unwavering commitment is the reason OpenBSD is so deeply respected and cherished.
Thank you for your perseverance and for setting an example of integrity in the technology community. This is why we love OpenBSD so much. Kind regards Sam On Wed, Feb 14, 2024 at 7:26 PM Theo de Raadt <dera...@openbsd.org> wrote: > Stuart Henderson <stu.li...@spacehopper.org> wrote: > > > On 2024-02-13, Samuel Jayden <samueljaydan1...@gmail.com> wrote: > > > From the information provided in the link, it appears that CARP and > VRRP > > > protocols aren't inherently interoperable. > > > > They are different protocols - they *had* to be different because VRRP > > was subject to patents. And if carp was changed now, it wouldn't be > > interoperable with existing carp installations. > > > > > While Cisco may have attempted to address this by introducing a command > > > like "disable-loop-detection carp" in its Nexus 1000V virtual router > > > product, this solution unfortunately doesn't extend to standard router > > > hardware, rendering it ineffective in many scenarios. > > > > That's not about interop beteeen carp and vrrp speakers, it's about > > using carp (or vrrp or hsrp or similar) on a port attached to the > > 'virtual switch'. See 'Information About Redundant Routing Protocols' on > > > https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus1000/sw/4_2_1_s_v_1_5_1/layer_2_switching/configuration/guide/n1000v_l2/n1000v_l2_7redundantroutingprot.html > > > > > Is it feasible to achieve CARP and VRRP interoperability through a > > > user-space application? > > > > No. They are different protocols. For what you want to do, running VRRP > > on the OpenBSD box might make some sense though. There are various > > existing userland implementations of VRRP that might be able to run > > on OpenBSD, probably with some work to port them - e.g. freevrrpd, > > frr-vrrpd, vrrpd. Nothing already in the ports tree (if someone wanted > > to try I'd suggest starting by looking at freevrrpd). > > This was my experience: > > VRRP was the first patent-encumbered protocol squeezed through the IETF > process. > > The backers of that change in process were employees and laywers at a few > major companies, but also tightly integrated into the IETF approval > process. > > When we objected to the VRRP situation, they circled the wagons, not just > to defend the VRRP patent, but to protect a future of patent's being OK in > IETF processes. > > In response, OpenBSD carefully developed a similar mechanism called CARP, > and the acronymn actually expands to "Cisco Asshole Redundancy Protocol", > because the main traitors inside IETF were Cisco employees. > > Then we asked IETF for numbers to make this a unique protocol. Unlike > a recent threads where Tatu asked IETF for port 22 and they just gave it > to him, the various number authorities inside IETF demanded that we follow > the most stringent procedures for CARP. Even to this day, IETF provides > the various prototol numbers to some large corporate industry members > without > forcing them down those stringent procedures. > > As a result, we simply squatted on the VRRP numbers. We gave them plenty > of warning we would be doing this. Over the following years, we heard some > real anger IETF decision makers internally, but none of them re-visited our > request for seperate numbers. We never got numbers. So CARP will stay > where it is. > > One major bug was in VRRP on some HP product was found in the first year. > CARP packets were incorrectly parsed as VRRP packets. I don't remember > the details, but I think it rebooted that HP device, probably a switch. > > Oh well. > >
