Re: US patent 5473599
* Blake Dunlap iki...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Robert Drake rdr...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Owen DeLong o...@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::) 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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Owen DeLong o...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Gary Buhrmaster gary.buhrmas...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Eygene Ryabinkin r...@grid.kiae.ru [2014-05-08 11:12]: Henning, Thu, May 08, 2014 at 09:35:00AM +0200, Henning Brauer wrote: * Blake Dunlap iki...@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. So, you insist that VRRP and CARP instances with the same VRID/VHID in the same L2 segment will coexist peacefully? I had seen problems with such setup, so if you can enlighten me how to overcome them (rather than saying you must choose different VRID/VHID) -- it will be very good. you shouldn't see issues but log spam. I haven't seen anotehr issue and I haven't seen a single report claiming otherwise over the last 10 years either, minus the mentioned cisco 3600 don't bother checking the version number field before parsing on screwup. -- Henning Brauer, h...@bsws.de, henn...@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
Re: US patent 5473599
* Saku Ytti s...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Nick Hilliard n...@foobar.org [2014-05-08 13:03]: On 08/05/2014 11:25, Henning Brauer wrote: you shouldn't see issues but log spam. maybe you misunderstand the problem. If you have vrrp and carp on the same vlan, using the same vrrp group ID as VHID, then each virtual IP will arp for the same mac address on that vlan. correct. This messes up the switch's forwarding table for that particular vlan because it sees multiple entries from different ports for the same mac address. correct. my switches seem to deal with that, wether they have special handling for that mac addr range or not i dunno. again, stress the fact that afair we have gotten zero reports about that issue for 10 years, it obviously means that either 1) a vast majority of switches deal with it just fine 2) people know that vhids shouldn't clash and avoid that -- Henning Brauer, h...@bsws.de, henn...@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
Re: US patent 5473599
* Bill Fenner fen...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* David Conrad d...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Jared Mauch ja...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Nick Hilliard n...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Donald Eastlake d3e...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Paul WALL pauldotw...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* TGLASSEY tglas...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Nick Hilliard n...@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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Nick Hilliard n...@foobar.org [2014-04-22 15:33]: 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. 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, h...@bsws.de, henn...@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
Re: US patent 5473599
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, h...@bsws.de, henn...@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
Re: US patent 5473599
* Ryan Shea ryans...@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, h...@bsws.de, henn...@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
Re: carping about CARP
* Robert E. Seastrom r...@seastrom.com [2012-11-30 13:46]: My problem is not with Theo nor with the IETF. My problem is with a crappy and credulous implementation. When an outage is caused by redundancy software that comes from an organization that prides itself on well-written code, the irony meter goes off the scale. vrrp and carp share the vhid space. you have to use unique vhids per network segment, that's about it. the openbsd box was nice enough to tell you about the mac address conflict, the other's didn't. if you looked at the carp boxes you had seen that carp had continued to work just fine. the mac address (which is basically fixed prefix + vhid) conflict is your outage. there's nothing we could do about that. and re IANA, they made it clear they would not give us a proto number no matter what; we didn't have a choice but to ignore that industry-money-driven committee. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Pica8 - Open Source Cloud Switch
* Lin Pica8 pica8@gmail.com [2010-10-18 13:27]: We are starting to distribute Pica8 Open Source Cloud Switches : open source? you gotta be joking. Currently, the Pica8 driver is released in binary form none of the interesting low-level drivers is open. none. zero. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Only 5x IPv4 /8 remaining at IANA
* Owen DeLong o...@delong.com [2010-10-18 17:27]: Have you done IPv6? I have... It's not even difficult(), let alone really().Really().Difficult(). maybe not from a users standpoint (that comes later when it misbehaves again). from an implementors (I have written a lot of kernel-side networking code and networking related daemons, including a full-blown bgpd, and that unfortunately included having to deal with v6) viewpoint - IPv6 is a desaster. Why people take up that crap is beyond me, instead of working on a viable alternative that doesn't suck. Which is certainly possible. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Pica8 - Open Source Cloud Switch
* Ricky Beam jfb...@gmail.com [2010-10-18 21:32]: On Mon, 18 Oct 2010 08:30:48 -0400, Henning Brauer hb-na...@bsws.de wrote: Currently, the Pica8 driver is released in binary form none of the interesting low-level drivers is open. none. zero. If it's based on a Broadcom chip, trust me, they are doing the world a favor by not exposing you to the SoC SDK. broadcom being too ashamed to show their code would not surprise me at all. however, that is no excuse. especially not when they try to market this as an open source switch. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: Software router state of the art
* Stuart Henderson [EMAIL PROTECTED] [2008-08-01 19:06]: On 2008-07-28, Joe Greco [EMAIL PROTECTED] wrote: I have yet to look into *BSD based solutions, but hear very good things about firewall performance. I don't know about BGP/OSPF/MPLS etc support on FreeBSD but am going to wager a guess its on par with Linux if not better. The underlying OS is responsible for packet forwarding, but none of them do any significant routing protocols natively. OpenBSD has OpenOSPFD/OpenBGPD in the base OS rather than as a port/ package, so it's fully coupled with any kernel changes (and supports some things missing from the FreeBSD port). can't be stressed enough; the concept of OpenBGPD/OSPFD/RIPD/DVRMPD/OSPF6D (did I forget one again?) is not too be just another daemon implementing the protocol at hand, they come with massive changes to the OpenBSD kernel to offer an alternative to other solutions, including hardware routers. Now it is quite clear that you don't want to run 5 loaded 10GE ports on any Hardware OpenBSD currently supports (it's not just PCs), but there are enough installations with smaller bandwidth requirements where it is a very viable alternative. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: [NANOG] 10GE router resource
* Aaron Glenn [EMAIL PROTECTED] [2008-03-26 03:14]: On Tue, Mar 25, 2008 at 6:15 PM, Patrick Clochesy [EMAIL PROTECTED] wrote: Very interesting study I had not seen, and a bummer. That really puts a cramp in my advocation of our CARP+pf load balancers/firewalls/gateways. Than again, what's a PIX box capable of? I'd rather tweak a whitebox than pay through the nose for a PIX. I also had to switch to OpenBSD as there was a fatal crash with the bridge device in FreeBSD when used with my paticular OpenVPN/CARP/pf combination. AFAIK pf/forwarding only takes place on one core and wouldn't take advantage of the other 3 cores, correct? Correct. There has been some great speed and efficiency improvements in pf and other networking parts of OpenBSD; though from anecdotal evidence, 10GbE is not ready for 'primetime' (for certain definitions of 'primetime'). actually I'll just skip making an ass out of myself and hope henning@ chimes in, since I believe he reads NANOG as well. occasionally. as with all other OSes constructed benchmarks would show 10GE to work at wirespeed with reasonable hardware. I would not use it (yet) if I truly need 10 GBit/s forwarding rate, and that goes for any OS. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
