On May 6, 2014, at 9:11 PM, Constantine A. Murenin <muren...@gmail.com> wrote:
On 6 May 2014 15:17, David Conrad <d...@virtualized.org> wrote:
Constantine,
On May 6, 2014, at 4:15 PM, Constantine A. Murenin <muren...@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
