[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
carping about CARP
- Subject: carping about CARP
- From: nick at foobar.org (Nick Hilliard)
- Date: Fri, 30 Nov 2012 12:44:27 +0000
- In-reply-to: <[email protected]>
- References: <[email protected]>
On 30/11/2012 05:52, Robert E. Seastrom wrote:
> [*] The OpenBSD side of the story can be read at
> Seems that there is a lesson to be learned here:
> "o hai, we wrote this software but can not be bothered to follow your
> process or formally write up the protocol, plz to be giving us a
> protocol number" ain't gonna fly.
Which is fair enough from the ietf's point of view. Having said that,
1. patent US5473599 is pretty general and I can't see why it wouldn't apply
to any host running CARP for router NHRP - although it's not clear that it
would apply to e.g. host service high availability addressing. IOW, it's
not at all clear that this is a legally unencumbered protocol, despite the
bleatings from the openbsd camp.
2. the original patent is due to expire in about 18 months (april 2014) and
i can't immediately see any cip applications which might extend it. This
will render the debate substantially redundant.
Regarding the ruckus between the openbsd camp and the ietf, the ietf's
position is here:
It looks like there wasn't any serious attempt on the part of the openbsd
people to engage with the ietf. There were no drafts, barely any mailing
list postings to either the vrrp (now concluded) or routing discussion WGs,
and apparently only a single presentation at a single ietf meeting. Maybe
I've missed something though - I haven't checked the openbsd mailing lists
because apparently their archives aren't publicly accessible.
It's not at all clear why the openbsd people expected that a "petition" to
IANA would result in them being assigned an official protocol number for
CARP. There are only 254 of these available so it's not unreasonable to
decline to register them unless there is a strong written case to do so.
There's a policy in place for this (rfc5237), and it's in place for a good
As for the openbsd position on the choice of protocol number:
"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
My goodness, what a co-incidence that they happened to choose the same
protocol number as VRRP.
Good thing this wasn't ever going to cause people trouble.