... turns 20 today. This is the patent which covers hsrp, vrrp, many applications of carp and some other vendor-specific standby protocols. Assuming no term adjustments, 20 years is the normal term for US patents so unless there's been any adjustments / continuations, probably this patent is now expired. More details on: https://www.google.com/patents/US5473599 Nick
* Nick Hilliard <nick@foobar.org> [2014-04-22 10:29]:
... turns 20 today.
This is the patent which covers hsrp, vrrp, many applications of carp and some other vendor-specific standby protocols.
it does NOT cover carp, not at all. carp was carefully designed to specifically avoid that. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On 22/04/2014 12:31, Henning Brauer wrote:
it does NOT cover carp, not at all.
that is a political statement rather than a legal opinion. If you read the patent, it's pretty obvious that when you have a group of carp-enabled devices providing a stable gateway IP address, and these devices are routing traffic received via the carp published address, this configuration provides the same functionality that's described in the patent claims. This hasn't been tested in court and neither of us is a lawyer and the patent seems to have expired, so it's academic at this stage. Nick
* Nick Hilliard <nick@foobar.org> [2014-04-22 15:33]:
it does NOT cover carp, not at all.
On 22/04/2014 12:31, Henning Brauer wrote: that is a political statement rather than a legal opinion. If you read the patent, it's pretty obvious that when you have a group of carp-enabled devices providing a stable gateway IP address, and these devices are routing traffic received via the carp published address, this configuration provides the same functionality that's described in the patent claims. This hasn't been tested in court and neither of us is a lawyer and the patent seems to have expired, so it's academic at this stage.
it is academic, indeed. I was involved with carp's creation, we did all the work to make sure it just avoids being covered by the patent. and that included getting legal advice. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On Tuesday, April 22, 2014, Henning Brauer <hb-nanog@bsws.de> wrote:
* Nick Hilliard <nick@foobar.org <javascript:;>> [2014-04-22 10:29]:
... turns 20 today.
This is the patent which covers hsrp, vrrp, many applications of carp and some other vendor-specific standby protocols.
it does NOT cover carp, not at all. carp was carefully designed to specifically avoid that.
CARP is a nonstandard protocol that was carefully designed to cause outages. Its authors submitted a slide deck describing their protocol instead of an internet-draft, which somehow managed to not get any traction in the IETF (funny that). The bar is pretty low for an informational RFC but the CARPheads couldn't be bothered. They threw a tantrum which involved camping out on the IETF's OUI (rather than getting their own) and deliberately choosing host bytes that conflict with the VRRP standard. This has the same predictable result as any duplicate MAC address, but since odds are it conflicts with a router, takes out the entire subnet instead of a single host. Of course this is not mentioned anywhere in CARP's documentation. That's why I encourage my competitors to run it. Drive slow, Paul
Great news about the patent age. Paul, sounds like this outage-causing catastrophe you mention could happen to your competitors _if_ they happened to run vrrp and carp on the same subnet _and_ happened to have a host identifier conflict - is that right? I just wanted to clarify. CARP has been a great solution for me in the past and is one of the features of BSD I think is great (along with OpenNTPd, OpenBGPd - which probably have similar standards non-compliance). Has anyone tried to use the userspace VRRP implementation on Linux... I recall delicacy and kludginess from the one time I used it - so again, CARP = rad. On Tue, Apr 22, 2014 at 9:20 AM, Paul WALL <pauldotwall@gmail.com> wrote:
On Tuesday, April 22, 2014, Henning Brauer <hb-nanog@bsws.de> wrote:
* Nick Hilliard <nick@foobar.org <javascript:;>> [2014-04-22 10:29]:
... turns 20 today.
This is the patent which covers hsrp, vrrp, many applications of carp and some other vendor-specific standby protocols.
it does NOT cover carp, not at all. carp was carefully designed to specifically avoid that.
CARP is a nonstandard protocol that was carefully designed to cause outages.
Its authors submitted a slide deck describing their protocol instead of an internet-draft, which somehow managed to not get any traction in the IETF (funny that). The bar is pretty low for an informational RFC but the CARPheads couldn't be bothered. They threw a tantrum which involved camping out on the IETF's OUI (rather than getting their own) and deliberately choosing host bytes that conflict with the VRRP standard. This has the same predictable result as any duplicate MAC address, but since odds are it conflicts with a router, takes out the entire subnet instead of a single host. Of course this is not mentioned anywhere in CARP's documentation.
That's why I encourage my competitors to run it.
Drive slow, Paul
* Ryan Shea <ryanshea@google.com> [2014-04-22 16:24]:
along with OpenNTPd, OpenBGPd - which probably have similar standards non-compliance
I wrote both of them, they are as standards compliant as it gets. we would have implemented vrrp if it hadn't been patent encumbered. in the end, that was even good, since carp, opposed to vrrp, has authentication and is address family independent. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
I won't waste time on your uninformed ramblings, you have the facts plain wrong. There is enough material on the net for everybody to read up on what happened. "carp causing outages" however is nothing short of a lie. carp announces itself as vrrp version 3. anything trying to parse it as vrrp2 without checking the version number in the header is buggy as hell and that is ITS fault, not carps. affected cisco 3600, afair. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On Tuesday, April 22, 2014, Henning Brauer <hb-nanog@bsws.de> wrote:
I won't waste time on your uninformed ramblings, you have the facts plain wrong. There is enough material on the net for everybody to read up on what happened.
"carp causing outages" however is nothing short of a lie. carp announces itself as vrrp version 3. anything trying to parse it as vrrp2 without checking the version number in the header is buggy as hell and that is ITS fault, not carps. affected cisco 3600, afair.
I wasn't talking about CARP's announcements causing outages due to bugs in VRRP implementations, I was talking about CARP's intentional use of another organization's OUI and deliberately constructing its bits in the host section to conflict with established practice for VRRP. That was childish, and causes outages. This design choice should be documented in CARP's man page. It is not. In response to Ryan Shea, here's the way it breaks down: Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made). The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck. If either of these decisions had not been made, we would not be having this discussion today. The last octet is the VRID for both CARP and VRRP. If you don't have the same VRID configured, the protocols should peacefully coexist, assuming no bugs in the software listening to the multicast advertisements (which Henning mentioned above - a legitimate concern to be sure, but not the big one). So yes, the problem only exists if you are running VRRP and CARP on the same subnet (say, a pair of routers speaking VRRP and a pair of firewalls backing each other with CARP and pfsync, which is actually fairly common) and happen to have a host identifier conflict. In a completely random world the likelihood of this is 1 in 256. Unfortunately, human nature and a plethora of examples on the intarwebs makes "interface GigabitEthernet 0/3 // vrrp 1 ip blah" reasonably likely. The same human nature causes the out of the box configuration on many products, e.g. pfSense, to be "ifconfig carp0 vhid 1". Presto - outage for everyone on the subnet. Soapbox time. There are some people who decide that they will only run FOSS software because of how they feel about software patents. In my case, I will not run CARP because of how I feel about folks deliberately violating the interoperability maxim ("be conservative in what you send and liberal in what you accept") and causing *me* to be the collateral damage. I think we all have enough on our plates dealing with legitimate software bugs without having rogue protocols deliberately interfering with our networks because of a grudge. Is CARP malware? A trojan? I'm not sure I'd go that far, but it seems to meet some of the definitions. Nothing personal Henning (and I like what you did with OpenBGPd and OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a bunch of other people's, if you publicly admitted the CARP OUI decision was a huge mistake. If your lawyers have advised you not to apologize because of liability concerns (despite that "no warranty" bit in the BSD license) it's OK - I completely understand. Drive Slow, Paul
On 04/22/2014 01:30 PM, Paul WALL wrote:
On Tuesday, April 22, 2014, Henning Brauer <hb-nanog@bsws.de> wrote:
I won't waste time on your uninformed ramblings, you have the facts plain wrong. There is enough material on the net for everybody to read up on what happened.
"carp causing outages" however is nothing short of a lie. carp announces itself as vrrp version 3. anything trying to parse it as vrrp2 without checking the version number in the header is buggy as hell and that is ITS fault, not carps. affected cisco 3600, afair.
I wasn't talking about CARP's announcements causing outages due to bugs in VRRP implementations, I was talking about CARP's intentional use of another organization's OUI and deliberately constructing its bits in the host section to conflict with established practice for VRRP. That was childish, and causes outages. This design choice should be documented in CARP's man page. It is not.
In response to Ryan Shea, here's the way it breaks down:
Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made).
The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck.
If either of these decisions had not been made, we would not be having this discussion today.
The last octet is the VRID for both CARP and VRRP. If you don't have the same VRID configured, the protocols should peacefully coexist, assuming no bugs in the software listening to the multicast advertisements (which Henning mentioned above - a legitimate concern to be sure, but not the big one).
So yes, the problem only exists if you are running VRRP and CARP on the same subnet (say, a pair of routers speaking VRRP and a pair of firewalls backing each other with CARP and pfsync, which is actually fairly common) and happen to have a host identifier conflict. In a completely random world the likelihood of this is 1 in 256. Unfortunately, human nature and a plethora of examples on the intarwebs makes "interface GigabitEthernet 0/3 // vrrp 1 ip blah" reasonably likely. The same human nature causes the out of the box configuration on many products, e.g. pfSense, to be "ifconfig carp0 vhid 1". Presto - outage for everyone on the subnet.
Soapbox time. There are some people who decide that they will only run FOSS software because of how they feel about software patents. In my case, I will not run CARP because of how I feel about folks deliberately violating the interoperability maxim ("be conservative in what you send and liberal in what you accept") and causing *me* to be the collateral damage. I think we all have enough on our plates dealing with legitimate software bugs without having rogue protocols deliberately interfering with our networks because of a grudge. Is CARP malware? A trojan? I'm not sure I'd go that far, but it seems to meet some of the definitions.
Nothing personal Henning (and I like what you did with OpenBGPd and OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a bunch of other people's, if you publicly admitted the CARP OUI decision was a huge mistake. If your lawyers have advised you not to apologize because of liability concerns (despite that "no warranty" bit in the BSD license) it's OK - I completely understand.
Drive Slow, Paul
I think there is also the issue it uses the same protocol number - 112. From /etc/protocolsvrrp 112 VRRP # Virtual Router Redundancy Protocol -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com
Imitation is the highest form of flattery. ;) Sent from my T-Mobile 4G LTE Device -------- Original message -------- From: Steve Clark <sclark@netwolves.com> Date: 04/22/2014 11:48 AM (GMT-07:00) To: Paul WALL <pauldotwall@gmail.com> Cc: nanog@nanog.org Subject: Re: US patent 5473599 On 04/22/2014 01:30 PM, Paul WALL wrote:
On Tuesday, April 22, 2014, Henning Brauer <hb-nanog@bsws.de> wrote:
I won't waste time on your uninformed ramblings, you have the facts plain wrong. There is enough material on the net for everybody to read up on what happened.
"carp causing outages" however is nothing short of a lie. carp announces itself as vrrp version 3. anything trying to parse it as vrrp2 without checking the version number in the header is buggy as hell and that is ITS fault, not carps. affected cisco 3600, afair.
I wasn't talking about CARP's announcements causing outages due to bugs in VRRP implementations, I was talking about CARP's intentional use of another organization's OUI and deliberately constructing its bits in the host section to conflict with established practice for VRRP. That was childish, and causes outages. This design choice should be documented in CARP's man page. It is not.
In response to Ryan Shea, here's the way it breaks down:
Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made).
The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck.
If either of these decisions had not been made, we would not be having this discussion today.
The last octet is the VRID for both CARP and VRRP. If you don't have the same VRID configured, the protocols should peacefully coexist, assuming no bugs in the software listening to the multicast advertisements (which Henning mentioned above - a legitimate concern to be sure, but not the big one).
So yes, the problem only exists if you are running VRRP and CARP on the same subnet (say, a pair of routers speaking VRRP and a pair of firewalls backing each other with CARP and pfsync, which is actually fairly common) and happen to have a host identifier conflict. In a completely random world the likelihood of this is 1 in 256. Unfortunately, human nature and a plethora of examples on the intarwebs makes "interface GigabitEthernet 0/3 // vrrp 1 ip blah" reasonably likely. The same human nature causes the out of the box configuration on many products, e.g. pfSense, to be "ifconfig carp0 vhid 1". Presto - outage for everyone on the subnet.
Soapbox time. There are some people who decide that they will only run FOSS software because of how they feel about software patents. In my case, I will not run CARP because of how I feel about folks deliberately violating the interoperability maxim ("be conservative in what you send and liberal in what you accept") and causing *me* to be the collateral damage. I think we all have enough on our plates dealing with legitimate software bugs without having rogue protocols deliberately interfering with our networks because of a grudge. Is CARP malware? A trojan? I'm not sure I'd go that far, but it seems to meet some of the definitions.
Nothing personal Henning (and I like what you did with OpenBGPd and OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a bunch of other people's, if you publicly admitted the CARP OUI decision was a huge mistake. If your lawyers have advised you not to apologize because of liability concerns (despite that "no warranty" bit in the BSD license) it's OK - I completely understand.
Drive Slow, Paul
I think there is also the issue it uses the same protocol number - 112. From /etc/protocolsvrrp 112 VRRP # Virtual Router Redundancy Protocol -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com
* Paul WALL <pauldotwall@gmail.com> [2014-04-22 19:30]:
Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made).
we're an open source project, running on a rather small budget almost exclusively from donations, so "quite reasonable" doesn't cut it.
The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck.
you're interpreting way too much in here. carp has been based on an earlier, never published vrrp implementatoin we had before realizing the patent problem. i don't remember any discussion about the OUI or, more general, the mac address choice. it's 10 years ago now, so i don't remember every single detail, changing the mac addr has pbly just been forgotten. not at least using sth but 00:01 for the 4th and 5th octet was likely a mistake. changing that now - wether just 4th/5th octet or to an entirely different, donated OUI - wouldn't be easy, unfortunately. acadmic discussion as long as we don't have a suitable OUI anyway.
If either of these decisions had not been made, we would not be having this discussion today.
we weren't really given a choice. as I said before, I'd much prefer we had just been given a multicast address etc. we tried. the IEEE/IETF/IANA processes have been an utter failure in our (limited) experience, not just in this case. might be different if you're $big_vendor with deep pockets, but that doesn't help either. fortunately this obviously isn't a big problem in practice, based on the fact that we don't get any complaints/reports in that direction. still would be way micer if that situation had been created in the first place, but as said - we weren't given that choice.
Nothing personal Henning (and I like what you did with OpenBGPd and OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a bunch of other people's, if you publicly admitted the CARP OUI decision was a huge mistake.
huge? nah. mistake? probably.
If your lawyers have advised you not to apologize because of liability concerns (despite that "no warranty" bit in the BSD license) it's OK - I completely understand.
you live in a bizarre world apparently. but then, that's what the US (dunno wether that is your actual background, sounds that way tho) is when it comes to patents and liability in the eyes of the rest of the world. neither of us can change that, so be it. and just to prevent confusion: I didn't implement most of carp, but was involved, and I wasn't the one dealing with IANA/IETF/whatever either. No pun intended if I mixed up IETF, IANA, IEEE somewhere here, it's not like we create new protocols every other day. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Henning I understand your work is important - and that its open source but that is part of the problem with global patent law today. No one wants it around when their works are impacted by it. But patent publications are binding under the treaties and in fact CARP clearly is an infringement. The issue is what to do do about it. Todd Glassey On 4/23/2014 9:47 AM, Henning Brauer wrote:
* Paul WALL <pauldotwall@gmail.com> [2014-04-22 19:30]:
Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made). we're an open source project, running on a rather small budget almost exclusively from donations, so "quite reasonable" doesn't cut it.
The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck. you're interpreting way too much in here. carp has been based on an earlier, never published vrrp implementatoin we had before realizing the patent problem. i don't remember any discussion about the OUI or, more general, the mac address choice. it's 10 years ago now, so i don't remember every single detail, changing the mac addr has pbly just been forgotten. not at least using sth but 00:01 for the 4th and 5th octet was likely a mistake. changing that now - wether just 4th/5th octet or to an entirely different, donated OUI - wouldn't be easy, unfortunately. acadmic discussion as long as we don't have a suitable OUI anyway.
If either of these decisions had not been made, we would not be having this discussion today. we weren't really given a choice. as I said before, I'd much prefer we had just been given a multicast address etc. we tried. the IEEE/IETF/IANA processes have been an utter failure in our (limited) experience, not just in this case. might be different if you're $big_vendor with deep pockets, but that doesn't help either.
fortunately this obviously isn't a big problem in practice, based on the fact that we don't get any complaints/reports in that direction. still would be way micer if that situation had been created in the first place, but as said - we weren't given that choice.
Nothing personal Henning (and I like what you did with OpenBGPd and OpenNTPd) but you'd gain a lot of respect in my eyes, as well as a bunch of other people's, if you publicly admitted the CARP OUI decision was a huge mistake. huge? nah. mistake? probably.
If your lawyers have advised you not to apologize because of liability concerns (despite that "no warranty" bit in the BSD license) it's OK - I completely understand. you live in a bizarre world apparently. but then, that's what the US (dunno wether that is your actual background, sounds that way tho) is when it comes to patents and liability in the eyes of the rest of the world. neither of us can change that, so be it.
and just to prevent confusion: I didn't implement most of carp, but was involved, and I wasn't the one dealing with IANA/IETF/whatever either. No pun intended if I mixed up IETF, IANA, IEEE somewhere here, it's not like we create new protocols every other day.
-- ------------- Personal Email - Disclaimers Apply
* TGLASSEY <tglassey@earthlink.net> [2014-04-23 19:13]:
in fact CARP clearly is an infringement [of the patent].
that's YOUR analysis, and it contradicts ours and the legal advice we got, so I'll ignore it. Irrelevant anyway, see subject - expired. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Hi, See below On Wed, Apr 23, 2014 at 12:47 PM, Henning Brauer <hb-nanog@bsws.de> wrote:
* Paul WALL <pauldotwall@gmail.com> [2014-04-22 19:30]:
Both CARP and VRRP use virtual router MAC addresses that start with 00:00:5e. This organizational unique identifier (OUI) is assigned to IANA, not OpenBSD or a related project. The CARP authors could have gotten their own from IEEE. OUIs are not free but the cost is quite reasonable (and was even more reasonable years ago when this unfortunate decision was made).
we're an open source project, running on a rather small budget almost exclusively from donations, so "quite reasonable" doesn't cut it.
While it is at the discretion of the IEEE Registration Authority, generally the IEEE RA will grant code point for standards use without any fee. While this is not all that clear from their web site, http://standards.ieee.org/develop/regauth/, except for standards use group (multicast) MAC addresses which are only for standards use and for which there is no charge, it is their policy.
The next two octets for IPv4 VRRP are 00:01. Highly coincidentally, the CARP folks *also* decided to use 00:01 after they got upset at the IETF for dissing their slide deck.
you're interpreting way too much in here. carp has been based on an earlier, never published vrrp implementatoin we had before realizing the patent problem. i don't remember any discussion about the OUI or, more general, the mac address choice. it's 10 years ago now, so i don't remember every single detail, changing the mac addr has pbly just been forgotten. not at least using sth but 00:01 for the 4th and 5th octet was likely a mistake. changing that now - wether just 4th/5th octet or to an entirely different, donated OUI - wouldn't be easy, unfortunately. acadmic discussion as long as we don't have a suitable OUI anyway.
If either of these decisions had not been made, we would not be having this discussion today.
we weren't really given a choice. as I said before, I'd much prefer we had just been given a multicast address etc. we tried. the IEEE/IETF/IANA processes have been an utter failure in our (limited) experience, not just in this case. might be different if you're $big_vendor with deep pockets, but that doesn't help either.
That seems like a very scatter-shot claim. The process for applying for MAC addresses under the IANA OUI was regularized in RFC 5342, since updated to and replaced by RFC 7042. See http://www.rfc-editor.org/rfc/rfc7042.txt. Perhaps you were trying before RFC 5342? To get an assignment under IANA it must bet or standard use that is either an IETF standard or related to an IETF standard but it doesn't say what the relationship has to be. It must also be documented in an Internet Draft or an RFC but there is no technical screening for posting an Internet Draft so that doesn't seem like a barrier. It is subject to expert review. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com
... ... -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
* Donald Eastlake <d3e3e3@gmail.com> [2014-04-23 21:46]:
The process for applying for MAC addresses under the IANA OUI was regularized in RFC 5342, since updated to and replaced by RFC 7042. See http://www.rfc-editor.org/rfc/rfc7042.txt. Perhaps you were trying before RFC 5342?
very possible. As I have said, I don't have to deal with IETF/IANA/IEEE often - we prefer to implement standards by far. I wasn't the one doing it for carp. We're talking about sth that happened 10 years ago. We ran against walls trying to get a multicast addr, and a protocol number for pfsync. Also as said before, the mac addr bit has pbly just been forgotten. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On 23/04/2014 17:47, Henning Brauer wrote:
fortunately this obviously isn't a big problem in practice, based on the fact that we don't get any complaints/reports in that direction. still would be way micer if that situation had been created in the first place, but as said - we weren't given that choice.
the situation was created by the openbsd team, not the ieee, the ietf or iana. You squatted on an existing oui assignment used by an equivalent protocol and in doing this, you created a long term problem with no possible solution other than to change carp to use its own dedicated range instead of someone else's. You had every choice in the world about what range to use and even if you didn't have the $2500 at the time to register a perpetual OUI assignment, almost any other OUI in existence would have been less detrimental to users than the one you chose. The openbsd foundation raised $153,000 this year. Why not invest $2500 of this and fix the problem? Nick
* Nick Hilliard <nick@foobar.org> [2014-04-26 22:56]:
the situation was created by the openbsd team, not the ieee, the ietf or iana.
that's nothing short of a lie.
The openbsd foundation raised $153,000 this year. Why not invest $2500 of this and fix the problem?
good luck finding another project of our size running on such a small budget. how about putting your money where your mouth is? this is all open source. when you don't like something or see a problem, there are always two options: 1) whine which doesn't change anything 2) work out a solution -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
On Tue, 06 May 2014 09:22:37 +0200, Henning Brauer said:
* Nick Hilliard <nick@foobar.org> [2014-04-26 22:56]:
the situation was created by the openbsd team, not the ieee, the ietf or iana.
that's nothing short of a lie.
Umm.. remind me who chose the conflicting value and shipped product that used it, when they knew (or should have known) that it would be in conflict? I'd almost accept an assertion that the issue wasn't recognized as a problem, or was believed to be a hypothetical that wouldn't happen in the real world. But trying to deny who picked the number doesn't help the situation.
On 6 May 2014 07:56, <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 06 May 2014 09:22:37 +0200, Henning Brauer said:
* Nick Hilliard <nick@foobar.org> [2014-04-26 22:56]:
the situation was created by the openbsd team, not the ieee, the ietf or iana.
that's nothing short of a lie.
Umm.. remind me who chose the conflicting value and shipped product that used it, when they knew (or should have known) that it would be in conflict?
I'd almost accept an assertion that the issue wasn't recognized as a problem, or was believed to be a hypothetical that wouldn't happen in the real world. But trying to deny who picked the number doesn't help the situation.
The situation is actually very clearly documented in the commentary to OpenBSD 3.5 release song on the web-site: http://www.openbsd.org/lyrics.html#35 Let me quote some excerpts:
As free software programmers, we therefore find ourselves in the position that these RAND standards must not be implemented by us, and we must deviate from the standard. We find all this rather Unreasonable and Discriminatory and we *will* design competing protocols. Some standards organization, eh?
On August 7 2002, after many communications, Robert Barr (Cisco's lawyer) firmly informed the OpenBSD community that Cisco would defend its patents for VRRP implementations -- meaning basically that it was impossible for a free software group to produce a truly free implementation of the IETF standard protocol.
We read the patent document carefully and ensured that CARP was fundamentally different. We also avoided many of the flaws in HSRP and VRRP (such as an inherent lack of security). And since we are OpenBSD developers, we designed it to use cryptography.
To date, we have built a few networks that include as many as 4 firewalls, all running random reboot cycles. As long as one firewall is alive in a group, traffic through them moves smoothly and correctly for all of our packet filter functionality. Cisco's low end products are unable to do this reliably, and if they have high end products which can do this, you most certainly cannot afford them.
As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization. Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply.
Frankly, I don't really see what the huge loss is. Perhaps people should realise that OpenBSD has recently removed The Heartbeat Extension from TLS in libssl, and boycott the upcoming LibreSSL, since its likelihood of having another heartbleed has been so reduced, yet the API is still compatible with OpenSSL. ??? C.
Constantine, On May 6, 2014, at 11:54 AM, Constantine A. Murenin <mureninc@gmail.com> wrote:
As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization.
Yes. The 8-bit IP protocol field is assigned by IANA according to "IESG Approval or Standards Action".
Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112.
Protocol 112 was assigned by IANA for VRRP in 1998. When did OpenBSD choose to squat on 112?
We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply.
I would imagine the reply was "IANA does not have discretion to assign those values, they are assigned by IESG or via a standards action." Indeed, IP protocol 240 is not yet allocated. Presumably the OpenBSD community expects everyone else to acknowledge the squatting on 240.
Frankly, I don't really see what the huge loss is.
Not surprising.
Perhaps people should realise that OpenBSD has recently removed The Heartbeat Extension from TLS in libssl, and boycott the upcoming LibreSSL, since its likelihood of having another heartbleed has been so reduced, yet the API is still compatible with OpenSSL. ???
Sorry, the relationship between OpenBSD developers intentionally and childishly squatting on a protocol number and OpenBSD developers hacking apart OpenSSL is what exactly? Regards, -drc
On 6 May 2014 12:31, David Conrad <drc@virtualized.org> wrote:
Constantine,
On May 6, 2014, at 11:54 AM, Constantine A. Murenin <mureninc@gmail.com> wrote:
As a final note of course, when we petitioned IANA, the IETF body regulating "official" internet protocol numbers, to give us numbers for CARP and pfsync our request was denied. Apparently we had failed to go through an official standards organization.
Yes. The 8-bit IP protocol field is assigned by IANA according to "IESG Approval or Standards Action".
Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112.
Protocol 112 was assigned by IANA for VRRP in 1998.
When did OpenBSD choose to squat on 112?
If you don't use it, you lose it.
We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply.
I would imagine the reply was "IANA does not have discretion to assign those values, they are assigned by IESG or via a standards action." Indeed, IP protocol 240 is not yet allocated. Presumably the OpenBSD community expects everyone else to acknowledge the squatting on 240.
Frankly, I don't really see what the huge loss is.
Not surprising.
Perhaps people should realise that OpenBSD has recently removed The Heartbeat Extension from TLS in libssl, and boycott the upcoming LibreSSL, since its likelihood of having another heartbleed has been so reduced, yet the API is still compatible with OpenSSL. ???
Sorry, the relationship between OpenBSD developers intentionally and childishly squatting on a protocol number and OpenBSD developers hacking apart OpenSSL is what exactly?
This all has been discussed ad nauseam over the years, in every possible forum, many times over again. There are only so many protocol numbers; out of those potentially available and non-conflicting, it was deemed the best choice to go with the protocol number that was guaranteed to be useless otherwise. Any complaints for Google using the https port 443 for SPDY? C.
Constantine, On May 6, 2014, at 4:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
Protocol 112 was assigned by IANA for VRRP in 1998.
When did OpenBSD choose to squat on 112?
If you don't use it, you lose it.
Are you suggesting no one is running VRRP? Surprising given RFC 5798. By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned.
There are only so many protocol numbers; out of those potentially available and non-conflicting,
Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned.
it was deemed the best choice to go with the protocol number that was guaranteed to be useless otherwise.
Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP).
Any complaints for Google using the https port 443 for SPDY?
AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. Regards, -drc
On 6 May 2014 15:17, David Conrad <drc@virtualized.org> wrote:
Constantine,
On May 6, 2014, at 4:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
Protocol 112 was assigned by IANA for VRRP in 1998.
When did OpenBSD choose to squat on 112?
If you don't use it, you lose it.
Are you suggesting no one is running VRRP? Surprising given RFC 5798.
By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned.
Your point being?
There are only so many protocol numbers; out of those potentially available and non-conflicting,
Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned.
it was deemed the best choice to go with the protocol number that was guaranteed to be useless otherwise.
Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol.
Can you explain why exactly do you find this odd? VRRP/HSRP have had only one protocol number allocated to it; it's not like it had two, so, another one had to come out of somewhere else.
To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP).
Any complaints for Google using the https port 443 for SPDY?
AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy.
Well, that's kinda the issue here -- the comparison with SPDY is actually quite valid. I haven't seen any facts that CARP actually precludes you from using VRRP on your network, unless you use broken VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing Cisco to fix those? or would you rather retain an extra attack vector for your routers?), or configure CARP and VRRP to use the same MAC addresses through the same Virtual ID setting (user error), when clearly a choice is available. On the contrary, it's actually clearly and unambiguously confirmed in this very thread that both could coexist just fine: http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html . So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID (VHID)" in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment. Why exactly is this not documented? You could always claim, "politics", and it probably was back then 10 years ago when this story developed; but, in today's reality, OpenBSD is quite well known for its minimalism in all things UNIX, just as Apple in all things visual design. The likelihood of someone mixing CARP and VRRP, on the same network segment / same VLAN, and with the same Virtual IDs, and without ever hearing of the controversies from which CARP had to be born (and being curious of the origins of the "cute" name), seems quite small to me. So, documenting it at this point would be quite pointless, if not only for the future generations or Google reference. So, just as always, much ado about nothing. If someone sends a good documentation patch, without making the change seem out of place, it'll probably be committed into the tree shortly. C.
On May 6, 2014, at 9:11 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
On 6 May 2014 15:17, David Conrad <drc@virtualized.org> wrote:
Constantine,
On May 6, 2014, at 4:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
Protocol 112 was assigned by IANA for VRRP in 1998.
When did OpenBSD choose to squat on 112?
If you don't use it, you lose it.
Are you suggesting no one is running VRRP? Surprising given RFC 5798.
By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned.
Your point being?
That the "BSD" community sometimes doesn't play well with others, and certainly won't fess up when they make a mistake and cause collateral damage. It's clear to me this discussion is becoming a losing prospect for all sides, it reminds me of all the small ways the BSD community has frustrated me, from not fixing defects found in -RC images that would prevent successful upgrades due to driver bugs to lack of hardware support.
There are only so many protocol numbers; out of those potentially available and non-conflicting,
Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned.
it was deemed the best choice to go with the protocol number that was guaranteed to be useless otherwise.
Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol.
Can you explain why exactly do you find this odd?
Because it's further polluting the ecosystem that we all depend on to operate properly. Asking for a number shouldn't be that hard and there are many people who can help shepherd these things through the community. The problem is when folks just squat on numbers and don't move. There have been collisions over the years that one can see documented in /etc/services on hosts that have been worked around, this isn't the first time, nor i'm sure will it be the last.
VRRP/HSRP have had only one protocol number allocated to it; it's not like it had two, so, another one had to come out of somewhere else.
Yes, I think the issue here is that CARP is the interloper. You don't mind me coming over and bringing my trash to your back yard do you?
To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP).
Any complaints for Google using the https port 443 for SPDY?
AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy.
Well, that's kinda the issue here -- the comparison with SPDY is actually quite valid. I haven't seen any facts that CARP actually precludes you from using VRRP on your network, unless you use broken VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing Cisco to fix those?
I'm certainly an advocate for fixing bugs in software. If OpenBSD has decided to participate in the community vs running off, I think you would have seen more "thanks" vs people being upset. I've been involved in a number of negative testing operations against router vendors that found defects. Did you work closely with a CERT or the PSIRT team? If not, that may be the sign of what is going on here.
or would you rather retain an extra attack vector for your routers?), or configure CARP and VRRP to use the same MAC addresses through the same Virtual ID setting (user error), when clearly a choice is available. On the contrary, it's actually clearly and unambiguously confirmed in this very thread that both could coexist just fine: http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html .
SPDY is sitting on the same well known port number but with a different protocol (udp vs tcp) so they can co-exist. There isn't really a true collision in the fact that an application listening to a socket will get the wrong packet. You either get SOCK_DGRAM or SOCK_STREAM.
So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID (VHID)" in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment.
Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else.
Why exactly is this not documented? You could always claim, "politics", and it probably was back then 10 years ago when this story developed; but, in today's reality, OpenBSD is quite well known for its minimalism in all things UNIX, just as Apple in all things visual design. The likelihood of someone mixing CARP and VRRP, on the same network segment / same VLAN, and with the same Virtual IDs, and without ever hearing of the controversies from which CARP had to be born (and being curious of the origins of the "cute" name), seems quite small to me. So, documenting it at this point would be quite pointless, if not only for the future generations or Google reference.
So, just as always, much ado about nothing. If someone sends a good documentation patch, without making the change seem out of place, it'll probably be committed into the tree shortly.
I think it's easy to interpret it as much ado about nothing, but clearly there are some scars on each side. - Jared
On 6 May 2014 18:51, Jared Mauch <jared@puck.nether.net> wrote:
On May 6, 2014, at 9:11 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
On 6 May 2014 15:17, David Conrad <drc@virtualized.org> wrote:
Constantine,
On May 6, 2014, at 4:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
Any complaints for Google using the https port 443 for SPDY?
AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy.
Well, that's kinda the issue here -- the comparison with SPDY is actually quite valid. I haven't seen any facts that CARP actually precludes you from using VRRP on your network, unless you use broken VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing Cisco to fix those?
I'm certainly an advocate for fixing bugs in software. If OpenBSD has decided to participate in the community vs running off, I think you would have seen more "thanks" vs people being upset. I've been involved in a number of negative testing operations against router vendors that found defects. Did you work closely with a CERT or the PSIRT team? If not, that may be the sign of what is going on here.
or would you rather retain an extra attack vector for your routers?), or configure CARP and VRRP to use the same MAC addresses through the same Virtual ID setting (user error), when clearly a choice is available. On the contrary, it's actually clearly and unambiguously confirmed in this very thread that both could coexist just fine: http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html .
SPDY is sitting on the same well known port number but with a different protocol (udp vs tcp) so they can co-exist. There isn't really a true collision in the fact that an application listening to a socket will get the wrong packet. You either get SOCK_DGRAM or SOCK_STREAM.
SPDY does not use UDP, it uses TCP. Check your facts. CARP uses a VRRP version number that has not been defined by VRRP, hence there is no conflict there, either. The link from the quote above has a quote from Henning.
So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID (VHID)" in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment.
Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else.
Politics. Again, this is a non-issue for most users -- there's a very easy, straightforward and complete workaround. C.
Constantine, Tue, May 06, 2014 at 06:11:04PM -0700, Constantine A. Murenin wrote:
On 6 May 2014 15:17, David Conrad <drc@virtualized.org> wrote:
Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol.
Can you explain why exactly do you find this odd?
VRRP/HSRP have had only one protocol number allocated to it; it's not like it had two, so, another one had to come out of somewhere else.
VRRP/HSRP comes from Cisco (well, VRRP is RFC'ed for some time, but its origin is Cisco too), so there is a straight route for agreeing on the protocol versioning within the same protocol ID. And _I_ find this odd is because you'll probably find me very odd if I'll come into your house, find currently unused room and will say "oh, I'll live here; no one will be confused or troubled, the room is unused". Seriously, do you think that "we used same protocol number, but version field tells you what's going on" is a really good excuse? Had you ever run tcpdump on the CARP traffic to see that it thinks it to be VRRP and discover that you need '-T carp'? Do you think that in-hardware or in-software implementations really need to check an extra field in the packet's contents to judge if this is VRRP (or CARP) instead of just testing protocol number and leave packets for unsupported protocol out of the path? Do you think that extra coordination with Cisco for not to reuse VRRP/HSRP protocol version that was at that time unused (and picked by CARP) really worth that? Tue, May 06, 2014 at 07:43:11PM -0700, Constantine A. Murenin wrote:
On 6 May 2014 18:51, Jared Mauch <jared@puck.nether.net> wrote:
On May 6, 2014, at 9:11 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID (VHID)" in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment.
Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else.
Politics. Again, this is a non-issue for most users -- there's a very easy, straightforward and complete workaround.
If you hadn't seen the cases when same VRIDs in the same network were used for both VRRP and CARP doesn't mean that they aren't occurring in the real world. We use CARP and VRRP quite extensively and when we first were hit by this issue, it was not that funny. And our Cisco folks had no knowledge about CARP, because they are just Cisco-heads (and because there is no CARP specification of any kind). Becides, such "clever" choice of OUI limits total number of CARP + HSRP/VRRP instances in the same L2 network to 256 instead of being 256 + 256. When you're running many CARP and VRRP-based clusters, especially with ARP load-balancing (multiple VRIDs for the single IP), this somewhat pushes VRID space close to its limits. One may say that (all that I had seen in the real-world conversations) a. people who use CARP and VRRP should know what they are both and avoid having same VRIDs; b. no sane person will use CARP load-balancing; c. the probability of having same VRIDs (and, thus, MACs) is small, but choosing OUI from the VRRP space (hijacking that space) was clearly the poor design choice. Fullstop. You may rant about Google, SPDY and other stuff, but making examples of people doing more cruel things doesn't help to alleviate the problem we're talking about. That's just the polite way of saying "CARP developers were right, piss off". Getting the same protocol ID and reusing OUI assignment is a potential point of confusion and errors. It manifests itself in the real world. Such potential points of breakage tend to strike at the worst possible time and current networks are complicated enough even without this mess; I think if you had worked in a complex network environments, you know what I am talking about. If not, well, just think of OSPF, BGP, BFD, VRRP, MPLS, LACP, PAgP, ESRP, xSTP and other protocols that are running today in any kinda matured network (not saying about other fancy stuff like TRILL, SDN and other ones that tend to show up and be even neccessary for some cases, but not very broadly deployed just now). Does anyone wants to have other problem-originators here? You appear to believe that it isn't an issue; well, that's your mindset. Other people think that there is some level of controversy in all this. Having the same protocol ID and OUI, but bumping the protocol version looks like as "hey, we have better VRRP our here, let's use that", but that didn't worked well, as we see now, and we have what we have: two incompatible protocols that use same IDs and sometimes they clash. Just learn the lesson and do the relevant parts of a protocol design better next time. And the "next time" can mean CARPv2 ;)) My personal view (if someone is interested) is that CARP did and still does very good job and at the time of its appearence of was technically superior vs VRRP/HSRP, just by having authentication. And it is/was free and non-patented thing that is a good stuff for some environments. But some points in CARP design are very rough and tend to create network mess. One can learn and avoid them, but it would be much better if these points were eliminated from the beginning or, at least, will be eliminated in the course of its further life. Shutting up. -- Eygene "using CARP and VRRP extensively" Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Eygene Ryabinkin <rea+nanog@grid.kiae.ru> writes:
If you hadn't seen the cases when same VRIDs in the same network were used for both VRRP and CARP doesn't mean that they aren't occurring in the real world. We use CARP and VRRP quite extensively and when we first were hit by this issue, it was not that funny.
+1
... but choosing OUI from the VRRP space (hijacking that space) was clearly the poor design choice. Fullstop.
+\infty Either it was an intentional conflict that was meant to cause operational problems or it was not. If it was, then a previous characterization of CARP as a trojan is spot on. If it was not (and I'm willing to be charitable here), then the take-away from this is that the folks who made this decision are utterly clueless about standards, the reason for standards, and operations. That would hardly be earth shattering news. Those wishing to decide for themselves which it is may wish to consider the fact that this tripping point remains undocumented in OpenBSD's man page ten years on. -r
On Wed, May 7, 2014 at 5:18 PM, Rob Seastrom <rs@seastrom.com> wrote:
Eygene Ryabinkin <rea+nanog@grid.kiae.ru> writes:
If you hadn't seen the cases when same VRIDs in the same network were used for both VRRP and CARP doesn't mean that they aren't occurring in the real world. We use CARP and VRRP quite extensively and when we first were hit by this issue, it was not that funny.
+1
... but choosing OUI from the VRRP space (hijacking that space) was clearly the poor design choice. Fullstop.
+\infty
Either it was an intentional conflict that was meant to cause operational problems or it was not.
If it was, then a previous characterization of CARP as a trojan is spot on.
If it was not (and I'm willing to be charitable here), then the take-away from this is that the folks who made this decision are utterly clueless about standards, the reason for standards, and operations. That would hardly be earth shattering news.
To be slightly less charitable, since I am having hard time coming up with a third option, I am forced to choose between maliciousness and incompetence. And I never thought the OpenBSD team was incompetent. Perhaps I was wrong? But (presuming no adjustments) the patent is now expired, and the OpenBSD team could now release CARPv2 (or whatever they decide to call it) which would implement the standard, should they wish to work and play well with the standards bodies and community. Gary
* Gary Buhrmaster <gary.buhrmaster@gmail.com> [2014-05-08 00:43]:
But (presuming no adjustments) the patent is now expired, and the OpenBSD team could now release CARPv2 (or whatever they decide to call it) which would implement the standard, should they wish to work and play well with the standards bodies and community.
why would we give up authentication and adress family independence? the vrrp dilemma forced us to invent carp instead, but now carp is far superior. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
If OBSD can't afford MAC addresses but does not object to them in principle, I can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee. -- ++ytti
* Saku Ytti <saku@ytti.fi> [2014-05-08 12:14]:
If OBSD can't afford MAC addresses but does not object to them in principle, I can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee.
congratulations, that is far ahead of just whining. when/if we change the mac addrs, the new range should be utterly correct and not just "a little bit better". not sure this would qualify. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
On Thu, May 08, 2014 at 12:31:23PM +0200, Henning Brauer wrote:
* Saku Ytti <saku@ytti.fi> [2014-05-08 12:14]:
If OBSD can't afford MAC addresses but does not object to them in principle, I can give forever IRU for 256 MAC addresses to OBSD for 0USD one-time fee.
when/if we change the mac addrs, the new range should be utterly correct and not just "a little bit better". not sure this would qualify.
I fail to see the issue with using these addresses, they are globally unique and correctly administrated at IEEE, Saku Ytti can do whatever he wants (like giving indefeasible rights of use to the OpenBSD Foundation). It won't come any cheaper than this (I am Dutch, I recognise a good deal when I see one!). If the team accepts I'll submit a patch to wireshark so decoded packets containing MACs from that block are properly identified as "OpenBSD". Kind regards, Job
On May 7, 2014, at 12:36 AM, Eygene Ryabinkin <rea+nanog@grid.kiae.ru> wrote:
VRRP/HSRP comes from Cisco (well, VRRP is RFC'ed for some time, but its origin is Cisco too),
I’m sorry, but this is 100% incorrect. HSRP comes from Cisco, but Cisco originally decided to not release the protocol to the IETF. [Stupid play on their part, but water under the bridge.] The IETF, realizing that this was useful technology, designed VRRP as a competitor to HSRP. Once that was well on its way to standardization, Cisco realized it missed the boat and finally publicly documented HSRP. Please get your facts straight. Tony
CARP uses a VRRP version number that has not been defined by VRRP, hence there is no conflict there, either. The link from the quote above has a quote from Henning.
Which means that in addition to squatting on the VRRP port, they are also squatting on a version number that I'm betting the IETF did not grant to them for that purpose and may use for another purpose at a later date. Owen
On 7 May 2014 15:09, Owen DeLong <owen@delong.com> wrote:
CARP uses a VRRP version number that has not been defined by VRRP, hence there is no conflict there, either. The link from the quote above has a quote from Henning.
Which means that in addition to squatting on the VRRP port,
VRRP protocol number, not port number. # fgrep carp /etc/protocols carp 112 CARP vrrp # Common Address Redundancy Protocol For the protocol which doesn't even leave the LAN.
they are also squatting on a version number that I'm betting the IETF did not grant to them for that purpose and may use for another purpose at a later date.
Yeah, right! How dare they?! The OpenBSD Project should have just closed the shop instead of providing an alternative and free virtual router/host redundancy protocol when Cisco said they're going to sue them if they implement the VRRP from the standards track! Who cares about the freedom of religion or expression? Everyone has to be Catholic and X, since that's what the state says. You can't even be an atheist or Y in the privacy of your own home and on your own LAN! Prohibited by IETF, since they might come over and take out your LAN! Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY, but OpenBSD cannot squat on the VRRP protocol with CARP? Especially since in the case of CARP, all communication is limited to a LAN segment? I mean, it is as if this non-standards-compliant-but-free CARP is being forced down your throat! Please enlighten us all on who's forcing CARP upon you. C. http://www.openbsd.org/lyrics.html#35
On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said:
Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY,
Because it doesn't squat on the port. It politely asks "Do you speak SPDY, or just https?" and then listens to what the other end replies.
On 7 May 2014 17:56, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said:
Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY,
Because it doesn't squat on the port. It politely asks "Do you speak SPDY, or just https?" and then listens to what the other end replies.
Same for CARP -- it has its own version number, so, there's no conflict with the VRRP spec, either. C.
Except for that whole mac address thing, that crashes networks... -Blake On Wed, May 7, 2014 at 8:03 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
On 7 May 2014 17:56, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said:
Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY,
Because it doesn't squat on the port. It politely asks "Do you speak SPDY, or just https?" and then listens to what the other end replies.
Same for CARP -- it has its own version number, so, there's no conflict with the VRRP spec, either.
C.
This CARP thing is the best troll I've seen yet. Over a decade old and people are still on about it. -Laszlo On May 8, 2014, at 1:15 AM, Blake Dunlap <ikiris@gmail.com> wrote:
Except for that whole mac address thing, that crashes networks...
-Blake
On Wed, May 7, 2014 at 8:03 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
On 7 May 2014 17:56, <Valdis.Kletnieks@vt.edu> wrote:
On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said:
Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY,
Because it doesn't squat on the port. It politely asks "Do you speak SPDY, or just https?" and then listens to what the other end replies.
Same for CARP -- it has its own version number, so, there's no conflict with the VRRP spec, either.
C.
* Blake Dunlap <ikiris@gmail.com> [2014-05-08 03:19]:
Except for that whole mac address thing, that crashes networks...
this lie doesn't get any more true by repeating them over and over. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
And that's why C. should use a more appropriate example to defend his position. By this thread, I suspect, that whoever dealt with those different organization for OpenBSD & CARP, lacked the skills to accomplish the task and got shut down for being an ass. PS: Being of the Church of FreeBSD, I freely acknowledge that I got no clue about the scope of the drama that CARP was involved with. But I was aware of Cisco/VRRP/HSRP patent and CARP and found CIsco to be a bit of a bully to actually enforce it for such a simple technology. That being said, I was never attracted to OpenBSD for some "gut" reason... I know why now =D ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 05/07/14 20:56, Valdis.Kletnieks@vt.edu wrote:
On Wed, 07 May 2014 17:10:32 -0700, "Constantine A. Murenin" said:
Also, would you please be so kind as to finally explain to us why Google can squat on the https port with SPDY, Because it doesn't squat on the port. It politely asks "Do you speak SPDY, or just https?" and then listens to what the other end replies.
* Jared Mauch <jared@puck.nether.net> [2014-05-07 03:54]:
That the "BSD" community sometimes doesn't play well with others
Translation: not bowing for corporate US america. Quite proudly so.
certainly won't fess up when they make a mistake
wrong. I have no problem admitting mistakes. And that's true for most of our devs. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
On May 6, 2014, at 23:44 , Henning Brauer <hb-nanog@bsws.de> wrote:
* Jared Mauch <jared@puck.nether.net> [2014-05-07 03:54]:
That the "BSD" community sometimes doesn't play well with others
Translation: not bowing for corporate US america. Quite proudly so.
Uh, no, Translation: Self appointed vigilantes with no regard for the rules by which everyone else has agreed to play.
certainly won't fess up when they make a mistake
wrong. I have no problem admitting mistakes. And that's true for most of our devs.
You seem to have a pretty big difficulty with it in this case. Owen
The issue Jared is needing a consensus in a community where that may be impossible to achieve because of differing agendas - so does that mean that the protocol should not exist because the IETF would not grant it credence? Interesting. Todd On 5/6/2014 6:51 PM, Jared Mauch wrote:
On May 6, 2014, at 9:11 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
On 6 May 2014 15:17, David Conrad <drc@virtualized.org> wrote:
Constantine,
On May 6, 2014, at 4:15 PM, Constantine A. Murenin <mureninc@gmail.com> wrote:
Protocol 112 was assigned by IANA for VRRP in 1998.
When did OpenBSD choose to squat on 112? If you don't use it, you lose it. Are you suggesting no one is running VRRP? Surprising given RFC 5798.
By the way, according to Wikipedia, it would seem the OpenBSD developers decided to squat on 112 in 2003, 5 years after 112 was assigned. Your point being? That the "BSD" community sometimes doesn't play well with others, and certainly won't fess up when they make a mistake and cause collateral damage. It's clear to me this discussion is becoming a losing prospect for all sides, it reminds me of all the small ways the BSD community has frustrated me, from not fixing defects found in -RC images that would prevent successful upgrades due to driver bugs to lack of hardware support.
There are only so many protocol numbers; out of those potentially available and non-conflicting, Yes. That is exactly why most responsible and professional developers work with IANA to obtain the assignments they need instead of intentionally squatting on numbers, particularly numbers known to be already assigned.
it was deemed the best choice to go with the protocol number that was guaranteed to be useless otherwise. Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. Can you explain why exactly do you find this odd? Because it's further polluting the ecosystem that we all depend on to operate properly. Asking for a number shouldn't be that hard and there are many people who can help shepherd these things through the community. The problem is when folks just squat on numbers and don't move. There have been collisions over the years that one can see documented in /etc/services on hosts that have been worked around, this isn't the first time, nor i'm sure will it be the last.
VRRP/HSRP have had only one protocol number allocated to it; it's not like it had two, so, another one had to come out of somewhere else. Yes, I think the issue here is that CARP is the interloper. You don't mind me coming over and bringing my trash to your back yard do you?
To be honest, it would seem from appearances that OpenBSD's use of 112 was deemed a "cute" (that is, unprofessional and irresponsible) way for the OpenBSD developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP).
Any complaints for Google using the https port 443 for SPDY? AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy. Well, that's kinda the issue here -- the comparison with SPDY is actually quite valid. I haven't seen any facts that CARP actually precludes you from using VRRP on your network, unless you use broken VRRP/HSRP implementations (BTW, did you thank OpenBSD for forcing Cisco to fix those? I'm certainly an advocate for fixing bugs in software. If OpenBSD has decided to participate in the community vs running off, I think you would have seen more "thanks" vs people being upset. I've been involved in a number of negative testing operations against router vendors that found defects. Did you work closely with a CERT or the PSIRT team? If not, that may be the sign of what is going on here.
or would you rather retain an extra attack vector for your routers?), or configure CARP and VRRP to use the same MAC addresses through the same Virtual ID setting (user error), when clearly a choice is available. On the contrary, it's actually clearly and unambiguously confirmed in this very thread that both could coexist just fine: http://mailman.nanog.org/pipermail/nanog/2014-April/066529.html . SPDY is sitting on the same well known port number but with a different protocol (udp vs tcp) so they can co-exist. There isn't really a true collision in the fact that an application listening to a socket will get the wrong packet. You either get SOCK_DGRAM or SOCK_STREAM.
So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID (VHID)" in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment. Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else.
Why exactly is this not documented? You could always claim, "politics", and it probably was back then 10 years ago when this story developed; but, in today's reality, OpenBSD is quite well known for its minimalism in all things UNIX, just as Apple in all things visual design. The likelihood of someone mixing CARP and VRRP, on the same network segment / same VLAN, and with the same Virtual IDs, and without ever hearing of the controversies from which CARP had to be born (and being curious of the origins of the "cute" name), seems quite small to me. So, documenting it at this point would be quite pointless, if not only for the future generations or Google reference.
So, just as always, much ado about nothing. If someone sends a good documentation patch, without making the change seem out of place, it'll probably be committed into the tree shortly. I think it's easy to interpret it as much ado about nothing, but clearly there are some scars on each side.
- Jared
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4577 / Virus Database: 3931/7451 - Release Date: 05/06/14
-- ------------- Personal Email - Disclaimers Apply
Hi, TGLASSEY wrote:
The issue Jared is needing a consensus in a community where that may be impossible to achieve because of differing agendas - so does that mean that the protocol should not exist because the IETF would not grant it credence? Interesting.
There are just 256 numbers available in https://www.iana.org/assignments/protocol-numbers. We could decide that we only assign them when there's a consensus or we could go with the alternative. Which do you prefer? There are a whole bunch of well-known policies. On the whole, the less limited the resource is the more liberal the policy. Maybe that's wrong and we should make everything FCFS. Regards, Leo
Todd, On May 7, 2014, at 4:44 PM, TGLASSEY <tglassey@earthlink.net> wrote:
The issue Jared is needing a consensus in a community where that may be impossible to achieve because of differing agendas - so does that mean that the protocol should not exist because the IETF would not grant it credence? Interesting.
Err, no. We're talking about a group that chose to squat on an existing assignment because they apparently didn't like the fact that the existing assignment had asserted intellectual property rights. As far as i can tell, it wasn't that the IETF would not grant CARP credence -- the IETF rules for IP protocol number assignment require either Standards Action or IESG Consensus. Did the OpenBSD developers even bother to document their protocol so the IESG could evaluate their request? However, assume that the OpenBSD developers did document their protocol and requested an IESG action and was refused. Do you believe that would justify squatting on an already assigned number? Regards, -drc
On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote:
However, assume that the OpenBSD developers did document their protocol and requested an IESG action and was refused. Do you believe that would justify squatting on an already assigned number?
I'm going to go with "yes", just to be contrary. At the point that the IESG refused to deal with 'em, they've effectively been ostracised from "the Internet community", and thus they are under no obligation to act within the rules and customs of that community. - Matt
Matt Palmer <mpalmer@hezmatt.org> writes:
On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote:
However, assume that the OpenBSD developers did document their protocol and requested an IESG action and was refused. Do you believe that would justify squatting on an already assigned number?
I'm going to go with "yes", just to be contrary. At the point that the IESG refused to deal with 'em, they've effectively been ostracised from "the Internet community", and thus they are under no obligation to act within the rules and customs of that community.
The bar for an informational RFC is pretty darned low. I don't see anything in the datagram nature of "i'm alive, don't pull the trigger yet" that would preclude a UDP packet rather than naked IP. Hell, since it's not supposed to leave the LAN, one could even get a different ethertype and run entirely outside of IP. Of course, the organization that has trouble coming up with the bucks for an OUI might have trouble coming up with the (2014 dollars) $2915 for a publicly registered ethertype too. Must be a pretty horrible existence ("I pity the fool"?) to live on donated resources but lack the creativity to figure out a way to run a special fund raiser for an amount worthy of a Scout troop bake sale. Makes you wonder what the OpenBSD project could accomplish if they had smart people who could get along with others to the point of shaking them down for tax-deductible donations, doesn't it? -r
Notwithstanding any legitimate or illegitimate grievance associated with the sordid history of carp / vrrp / the us patent system / BSD forks and their respective participants. It's time to take a long weekend. thanks joel On 5/7/14, 8:47 PM, Rob Seastrom wrote:
Matt Palmer <mpalmer@hezmatt.org> writes:
On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote:
However, assume that the OpenBSD developers did document their protocol and requested an IESG action and was refused. Do you believe that would justify squatting on an already assigned number?
I'm going to go with "yes", just to be contrary. At the point that the IESG refused to deal with 'em, they've effectively been ostracised from "the Internet community", and thus they are under no obligation to act within the rules and customs of that community.
The bar for an informational RFC is pretty darned low. I don't see anything in the datagram nature of "i'm alive, don't pull the trigger yet" that would preclude a UDP packet rather than naked IP. Hell, since it's not supposed to leave the LAN, one could even get a different ethertype and run entirely outside of IP. Of course, the organization that has trouble coming up with the bucks for an OUI might have trouble coming up with the (2014 dollars) $2915 for a publicly registered ethertype too.
Must be a pretty horrible existence ("I pity the fool"?) to live on donated resources but lack the creativity to figure out a way to run a special fund raiser for an amount worthy of a Scout troop bake sale. Makes you wonder what the OpenBSD project could accomplish if they had smart people who could get along with others to the point of shaking them down for tax-deductible donations, doesn't it?
-r
On 5/7/2014 9:47 PM, Rob Seastrom wrote:
The bar for an informational RFC is pretty darned low. I don't see anything in the datagram nature of "i'm alive, don't pull the trigger yet" that would preclude a UDP packet rather than naked IP. Hell, since it's not supposed to leave the LAN, one could even get a different ethertype and run entirely outside of IP. Of course, the organization that has trouble coming up with the bucks for an OUI might have trouble coming up with the (2014 dollars) $2915 for a publicly registered ethertype too.
Meh.. it's open source. If I design a toaster that spits flames when you put bagels in it, then I put the design on github and forget about it, I shouldn't be held responsible for someone adding it to their network and setting fire to a router or two. A problem that the developer doesn't have isn't a problem. Oh, the user community noticed an interoperability issue? What user community? I was building this toaster for myself. I released the plans in case it inspires or helps others. If fire isn't what you need then maybe you can modify it to do what's needed.* Now, the bar for an informational RFC is pretty low. Especially for people who have written them before. Those people seem to think one is needed in this case so they might want to get started writing it. Then patches to the man pages covering the past issues can be added to document things, and a patch can be issued with the new OUI, ethertype, or port number, whichever the RFC decides to go for.
Must be a pretty horrible existence ("I pity the fool"?) to live on donated resources but lack the creativity to figure out a way to run a special fund raiser for an amount worthy of a Scout troop bake sale. Makes you wonder what the OpenBSD project could accomplish if they had smart people who could get along with others to the point of shaking them down for tax-deductible donations, doesn't it?
-r
The money could also be donated by parties interested in solutions. Open source is about people finding a problem and fixing it for their own benefit then giving the fix away to the community for everyone's benefit. I know in the past the OpenBSD community has been harsh with outsiders who submit patches. I honestly expect the same response in this case, especially because of the underlying drama associated with it, but without trying first it just seems like the network community is whining without being helpful at all. To be fair, we're used to dealing with vendors where we can't change things so we bitch about them until they fix code for us. In this case there is no "them" to bitch about. We (the community) wrote the code and it's up to us to fix it. If you don't consider yourself part of the OpenBSD community then you shouldn't be using their products and encountering problems, right? * yeah, that's a very insular view and not really acceptable in the grown up world, but everyone's been beating them down over this and sometimes you end up taking your ball and going home because you're tired of people criticizing your plays.
On May 7, 2014, at 20:58 , Robert Drake <rdrake@direcpath.com> wrote:
On 5/7/2014 9:47 PM, Rob Seastrom wrote:
The bar for an informational RFC is pretty darned low. I don't see anything in the datagram nature of "i'm alive, don't pull the trigger yet" that would preclude a UDP packet rather than naked IP. Hell, since it's not supposed to leave the LAN, one could even get a different ethertype and run entirely outside of IP. Of course, the organization that has trouble coming up with the bucks for an OUI might have trouble coming up with the (2014 dollars) $2915 for a publicly registered ethertype too.
Meh.. it's open source. If I design a toaster that spits flames when you put bagels in it, then I put the design on github and forget about it, I shouldn't be held responsible for someone adding it to their network and setting fire to a router or two.
A problem that the developer doesn't have isn't a problem. Oh, the user community noticed an interoperability issue? What user community? I was building this toaster for myself. I released the plans in case it inspires or helps others. If fire isn't what you need then maybe you can modify it to do what's needed.*
Now, the bar for an informational RFC is pretty low. Especially for people who have written them before. Those people seem to think one is needed in this case so they might want to get started writing it. Then patches to the man pages covering the past issues can be added to document things, and a patch can be issued with the new OUI, ethertype, or port number, whichever the RFC decides to go for.
Must be a pretty horrible existence ("I pity the fool"?) to live on donated resources but lack the creativity to figure out a way to run a special fund raiser for an amount worthy of a Scout troop bake sale. Makes you wonder what the OpenBSD project could accomplish if they had smart people who could get along with others to the point of shaking them down for tax-deductible donations, doesn't it?
-r
The money could also be donated by parties interested in solutions.
Open source is about people finding a problem and fixing it for their own benefit then giving the fix away to the community for everyone's benefit. I know in the past the OpenBSD community has been harsh with outsiders who submit patches. I honestly expect the same response in this case, especially because of the underlying drama associated with it, but without trying first it just seems like the network community is whining without being helpful at all.
To be fair, we're used to dealing with vendors where we can't change things so we bitch about them until they fix code for us. In this case there is no "them" to bitch about. We (the community) wrote the code and it's up to us to fix it. If you don't consider yourself part of the OpenBSD community then you shouldn't be using their products and encountering problems, right?
* yeah, that's a very insular view and not really acceptable in the grown up world, but everyone's been beating them down over this and sometimes you end up taking your ball and going home because you're tired of people criticizing your plays.
If they take their ball and go home, that's fine. The problem is that they seem to occasionally have their ball brought (by systems administrators) to networks where the network engineers are already running VRRP on routers (for example) and because: 1. The systems administrators don't necessarily have in-depth knowledge of what the network is doing. 2. The network administrators don't necessarily get told about every detail of the Systems administrators intentions. 3. There's no knowledge among the two groups that either is using the other protocol (CARP vs. VRRP) 4. There's even less knowledge that the two are going to fight with each other. 5. You encounter a network outage where the network engineers spend a bunch of time chasing down rogue duplicate MAC addresses messing up the switch forwarding tables until they find the (recently activated) systems CRAP^H^H^HARPing all over their network and breaking it for everyone. OTOH, if the BSD folk had (or in the future did) fix CARP so that instead of trying to steal VRRP MAC addresses in a conflicting manner, it would either use a non-conflicting MAC prefix (how about one with the locally assigned bit set, such as the VRRP Mac | 0x02000:0000:0000) and make a legitimate attempt at getting CARP into an RFC with a legitimately assigned protocol number, everyone could get along without issue. Yes, you can work around the current issue ONCE YOU KNOW ABOUT IT. Unfortunately, the most common way of learning about this particular little lovely OpenBSD time-bomb is when it explodes all over a previously operational network, usually rendering it non-operational until the problem can be identified, usually by people who had no knowledge of how it got created. Owen
* Owen DeLong <owen@delong.com> [2014-05-08 07:16]:
If they take their ball and go home, that's fine. The problem is that they seem to occasionally have their ball brought (by systems administrators) to networks where the network engineers are already running VRRP on routers (for example) and because:
1. The systems administrators don't necessarily have in-depth knowledge of what the network is doing.
nothing technology can solve
2. The network administrators don't necessarily get told about every detail of the Systems administrators intentions.
nothing technology can solve
3. There's no knowledge among the two groups that either is using the other protocol (CARP vs. VRRP)
nothing technology can solve
4. There's even less knowledge that the two are going to fight with each other.
that is a lie, they coexist just fine. even with "conflicting" mac addrs you just get log spam.
OTOH, if the BSD folk had (or in the future did) fix CARP so that instead of trying to steal VRRP MAC addresses in a conflicting manner, it would either use a non-conflicting MAC prefix (how about one with the locally assigned bit set, such as the VRRP Mac | 0x02000:0000:0000) and make a legitimate attempt at getting CARP into an RFC with a legitimately assigned protocol number, everyone could get along without issue.
awaiting your diff. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
On Thu, May 08, 2014 at 09:48:26AM +0200, Henning Brauer wrote:
awaiting your diff.
http://marc.info/?l=openbsd-tech&m=139955603603070&w=2 Kind regards, Job
* Robert Drake <rdrake@direcpath.com> [2014-05-08 06:02]:
On 5/7/2014 9:47 PM, Rob Seastrom wrote: Now, the bar for an informational RFC is pretty low. Especially for people who have written them before. Those people seem to think one is needed in this case so they might want to get started writing it. Then patches to the man pages covering the past issues can be added to document things, and a patch can be issued with the new OUI, ethertype, or port number, whichever the RFC decides to go for.
spot on. but apparently nanog is just about whining for the sake of whining.
Must be a pretty horrible existence ("I pity the fool"?) to live on donated resources but lack the creativity to figure out a way to run a special fund raiser for an amount worthy of a Scout troop bake sale. Makes you wonder what the OpenBSD project could accomplish if they had smart people who could get along with others to the point of shaking them down for tax-deductible donations, doesn't it? The money could also be donated by parties interested in solutions.
again, spot on.
Open source is about people finding a problem and fixing it for their own benefit then giving the fix away to the community for everyone's benefit. I know in the past the OpenBSD community has been harsh with outsiders who submit patches. I honestly expect the same response in this case, especially because of the underlying drama associated with it, but without trying first it just seems like the network community is whining without being helpful at all.
I think we are pretty damn open for patches from outside. And I have said it before, if somebody does the work and gives us a mac addr range to use without unreasonable terms and conditions attached, we'll almost certainly use it. Chances increased if it is a full patch with code for the transition period. Sorry, doesn't fit nanog, since that would require work instead of just whining and bitching. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
On May 7, 2014, at 4:19 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote:
However, assume that the OpenBSD developers did document their protocol and requested an IESG action and was refused. Do you believe that would justify squatting on an already assigned number?
I'm going to go with "yes", just to be contrary. At the point that the IESG refused to deal with 'em, they've effectively been ostracised from "the Internet community", and thus they are under no obligation to act within the rules and customs of that community.
- Matt
I don’t believe for one second that the IESG refused to deal with ‘em. I do believe the IESG did not hand them everything they wanted on a silver platter in contravention of the established consensus process and that they failed to gain the consensus they wanted as easily as they hoped. I’d say they are not, in fact ostracized or even disenfranchised and that their abrogation of their obligations to act within the rules and customs of the internet community in developing network protocols for IP is more like a temper tantrum than a legitimate grievance. Owen
On Wed, May 07, 2014 at 07:33:45PM -0700, Owen DeLong wrote:
On May 7, 2014, at 4:19 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
On Wed, May 07, 2014 at 05:57:01PM -0400, David Conrad wrote:
However, assume that the OpenBSD developers did document their protocol and requested an IESG action and was refused. Do you believe that would justify squatting on an already assigned number?
I'm going to go with "yes", just to be contrary. At the point that the IESG refused to deal with 'em, they've effectively been ostracised from "the Internet community", and thus they are under no obligation to act within the rules and customs of that community.
I don’t believe for one second that the IESG refused to deal with ‘em.
Neither do I. That wasn't the question I was answering, though -- the scenario described was "assume that...". - Matt
* Owen DeLong <owen@delong.com> [2014-05-08 04:36]:
I don’t believe for one second that the IESG refused to deal with ‘em.
you're free to believe whatever you want and ignore facts.
I do believe the IESG did not hand them everything they wanted on a silver platter in contravention of the established consensus process and that they failed to gain the consensus they wanted as easily as they hoped.
lie. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
On Thu, May 8, 2014 at 3:49 AM, Henning Brauer <hb-nanog@bsws.de> wrote:
* Owen DeLong <owen@delong.com> [2014-05-08 04:36]:
I don’t believe for one second that the IESG refused to deal with ‘em.
you're free to believe whatever you want and ignore facts.
I do believe the IESG did not hand them everything they wanted on a silver platter in contravention of the established consensus process and that they failed to gain the consensus they wanted as easily as they hoped.
lie.
I was the IESG member responsible for the VRRP working group when the OpenBSD developer (I'm sorry, Henning, I forget if it was you or someone else) came to a VRRP WG meeting and demanded that the IETF handle the patent issue with VRRP. We described the IETF's IPR process and that the policy is explicitly not to do what was being requested, and the response was more or less "well, then we'll have to fix the problem for you". At later meetings I heard buzz about how the developers intended CARP to interfere with VRRP, with the philosophical position that VRRP wasn't a protocol. When I first saw the claims that IANA told OpenBSD that you had to have deep pockets to get a protocol number, I asked the IANA to share the original request and any related correspondence with the IESG. They could not find any such correspondence in the raw archive of the iana@iana.orgmailbox. While the OpenBSD project has done an incredible amount of good on the Internet, the version of events described by the 3.5 release song does not match my personal experiences. Bill
* Bill Fenner <fenner@gmail.com> [2014-05-08 20:41]:
I was the IESG member responsible for the VRRP working group when the OpenBSD developer (I'm sorry, Henning, I forget if it was you or someone else)
wasn't me, as stated repeatedly I wasn't the one talking to the standard bodies.
came to a VRRP WG meeting and demanded that the IETF handle the patent issue with VRRP. We described the IETF's IPR process and that the policy is explicitly not to do what was being requested, and the response was more or less "well, then we'll have to fix the problem for you". At later meetings I heard buzz about how the developers intended CARP to interfere with VRRP, with the philosophical position that VRRP wasn't a protocol.
I think we have told what happened in enough detail in the 3.5 commentary already posted to this thread. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the "xx" part comes from the "Virtual Router IDentifier (VRID)" in VRRP and "virtual host ID (VHID)" in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment.
RFC 2338, from April 1998: 7.3 Virtual Router MAC Address The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format: 00-00-5E-00-01-{VRID} (in hex in internet standard bit-order) The first three octets are derived from the IANA's OUI. The next two octets (00-01) indicate the address block assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping provides for up to 255 VRRP routers on a network. Also repeated in RFC 3768 (April 2004) and RFC 5798 (March 2010). Steinar Haug, Nethelp consulting, sthaug@nethelp.no
* David Conrad <drc@virtualized.org> [2014-05-07 00:21]:
The fact that OpenBSD developers continue to defend this choice is one reason why I won't run OpenBSD (or CARP).
We won't miss you. And besides, you're running plenty of our code every day. It's probaby in your pocket right now.
Any complaints for Google using the https port 443 for SPDY? AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network.
The use of CARP does not preclude the use of VRRP on the same network either.
The fact that in addition to the OpenBSD developers choosing to use 112, they also chose to use the MAC addresses used for VRRP, thus making it impossible to run both VRRP and CARP on the same network due to MAC address conflicts would suggest you might want to pick a better analogy.
How about checking your facts before making wrong claims next time? carp and vrrp work prefectly fine next to each other on the same network. I explained what lead to the mac addr at least twice right in this thread. Amazing how many people here apparently have text understanding issues. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services GmbH, AG Hamburg HRB 128289, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, VMs/PVS, Application Hosting
On Apr 26, 2014, at 1:55 PM, Nick Hilliard <nick@foobar.org> wrote:
the situation was created by the openbsd team, not the ieee, the ietf or iana. You squatted on an existing oui assignment used by an equivalent protocol and in doing this, you created a long term problem with no possible solution other than to change carp to use its own dedicated range instead of someone else's.
You had every choice in the world about what range to use and even if you didn't have the $2500 at the time to register a perpetual OUI assignment, almost any other OUI in existence would have been less detrimental to users than the one you chose.
The openbsd foundation raised $153,000 this year. Why not invest $2500 of this and fix the problem?
Sorry this is late… Might I suggest an even simpler and cheaper solution? Cisco has widely and repeatedly claimed that they will only use their patents defensively. Why not have someone on behalf of *BSD simply write them a letter/email requesting a royalty-free license to the patent for use in *BSD? Play up the non-profit and non-competitive angles. If they agree, then you can freely implement HSRP or VRRP directly. If they refuse, then you’re no worse off than you were before. The guy with his name on the patent, Tony
participants (29)
-
Alain Hebert -
Bill Fenner -
Blake Dunlap -
Constantine A. Murenin -
David Conrad -
Donald Eastlake -
Eygene Ryabinkin -
Gary Buhrmaster -
Henning Brauer -
Jared Mauch -
Job Snijders -
joel jaeggli -
Laszlo Hanyecz -
Leo Vegoda -
Matt Palmer -
Nick Hilliard -
Owen DeLong -
Paul WALL -
Randy Bush -
Rob Seastrom -
Robert Drake -
Ryan Shea -
Saku Ytti -
Steve Clark -
sthaug＠nethelp.no -
TGLASSEY -
Tony Li -
Valdis.Kletnieks＠vt.edu -
Warren Bailey