US patent 5473599

Thu May 8 05:04:23 UTC 2014

On May 7, 2014, at 20:58 , Robert Drake <rdrake at 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