I've been working on a personal project that involves creating a new network protocol. Out of curiosity, I tried to find out what would be involved in getting an official protocol number assigned for my project and discovered that it could take a year and could mean a lot of back and forth with the powers that be at the IETF (Internet Engineering Task Force). I knew this wouldn't be as simple as clicking something on a Web page, but a year seems excessive, and really it's not a major part of the work, so it seems like this would mainly be a distraction. For now, I just took a random protocol number that I know doesn't conflict with anything on my network—such as UDP or TCP—and things seem to work fine. I guess my real question is why would anyone bother to go to the IETF to ask for this unless they were a company that could waste someone's time on an e-mail campaign to get a properly assigned number?
Let me begin by complimenting you on the fact that you actually went so far as to find out how one might do this correctly. (I am sure that many readers have just spit coffee on their screens, because none of them can remember the last time I complimented a writer to this column.) I compliment you because just recently I came across someone who knew the right thing to do, and then did exactly the opposite.
Because of some of the assumptions present in the original design of the Internet, some parts of the IPv4 packet header are far more precious than others, and, while the limitations of the 32-bit network address get the largest amount of attention, the 8-bit protocol field is equally as important, if not more so. With an 8-bit field, we can layer only 255 possible protocols on top of IPv4, which may seem like a lot, and since most people assume that all IP packets carry only TCP, protocol 6, there is plenty of space. It turns out that more than half of the numbers have been used for one protocol or another, leaving only 109 for use by authors of new protocols. Another problem is that IPv6, the nominal savior of the Internet, with its wider network addresses, still uses an 8-bit protocol field, so we're not getting any more space any time soon.
The protocol field can be seen as a commons for the Internet, so let me tell you a tragedy, and one that didn't have to happen. It is a story of hubris and zealotry, and unsurprisingly, involves the collision between corporations and open source.
Sometime in the late 1990s, a group of companies got together and proposed a protocol that would be standardized within the aegis of the IETF. It's not particularly important what the protocol does, but it's called VRRP (Virtual Router Redundancy Protocol) and exists so that two or more routers can act as peers in a fail-over scenario. If one router fails, another router discovers this via a means described in the protocol and takes over for the failing router. After the standard was published, two companies—Cisco and IBM—both claimed to have patents to some of what the protocol did. Cisco released its claimed intellectual property under a RAND (reasonable and nondiscriminatory) license. In nonlegal terms this means that people could implement VRRP, and Cisco would not chase them down with expensive claims. RAND licenses are often used in software standardization processes.
Unfortunately, there is a segment of the open source community that is incapable of playing well with others, when those others don't play the way they want them to. For those who have not had to deal with these people, it's a bit like talking to a four-year-old. When you explain checkers to your niece, she might decide that she doesn't like your rules and follows her own rules. You humor her, she's being creative, and this is amusing in a four-year-old. If you were playing chess with a colleague who suddenly told you that the king could move one, two, or three places in one go, you would be pissed off, because this person would obviously be screwing with you, or insane.
Have I lost my mind?! What does this have to do with VRRP or network protocols?
The OpenBSD team, led as always by their Glorious Leader (their words, not mine), decided that a RAND license just wasn't free enough for them. They wrote their own protocol, which was completely incompatible with VRRP. Well, you say, that's not so bad; that's competition, and we all know that competition is good and brings better products, and it's the glorious triumph of Capitalism. But there is one last little nit to this story. The new protocol dubbed CARP (Common Address Redundancy Protocol) uses the exact same IP number as VRRP (112). Most people, and KV includes himself in this group, think this was a jerk move. "Why would they do this?" I hear you cry. Well, it turns out that they believe themselves to be in a war with the enemies of open source, as well as with those opposed to motherhood and apple pie. Stomping on the same protocol number was, in their minds, a strike against their enemies and all for the good. Of course, it makes operating devices with both protocols in the same network difficult, and it makes debugging the software that implements the protocol nearly impossible.
In the end the same thing is going to happen as happens when your four-year-old niece up-ends the checkers game in frustration. She runs away crying, and you're left to pick up the pieces. A few of us now have to take this protocol and actually get it a proper protocol number and then deal with the fact that legacy devices are still using the old, incompatible protocol.
Now I think you see why I wanted to compliment you. Doing the right thing in the commons is good for all of us. Thanks for not being a jerk.
One of my coworkers seems to be completely allergic to useful tools. For example, rather than extend a program to interpret new data properly in one of our log generators, he instead memorizes the format and reads it off the screen when something breaks. He seems to take great pride in this, but I'm not really sure why. Wouldn't a tool make more sense?
Hexed by Dumps
I'm not really sure how many variations on the theme of "Tools are Useful" I will eventually write, but clearly my message has not penetrated to the depth that I would like. In part, I think the problem is that geeks—and I include myself in this group—get off on feeling that they know things—in particular, things that they think others don't know. You can see this in the in-jokes we tell one another, such as the number of times the number 42 appears in code. It is this love of arcana, I think, that leads people to be proud of the fact that they can get along by reading hex dumps.
Of course, the problem is that some ways of looking at data are more prone to error than others. For example, as someone who looks at a lot of network packets, I can tell you that the following
0x0000: 4500 0045 bf49 0000 ff11 7902 c0a8 010a
0x0010: c0a8 0101 d688 0035 0031 8a10 39e6 0100
0x0020: 0001 0000 0000 0000 0c70 3034 2d75 6269
0x0030: 7175 6974 7906 6963 6c6f 7564 0363 6f6d
0x0040: 0000 0100 01
is an IPv4 packet, and I can then scan through it to find the IP addresses and other bits that I need to know to diagnose what's wrong with a host's network connection. Compared with the above, though, I would rather read this:
Sure, the second example is also gobbledygook to the average person, but it's far easier to read and understand for the professional who is trying to get a job done. It's also just as compact as the first example, so an argument cannot even be made that the hex dump is quicker to read. The real issue is that getting a job done is what so many geeks lose sight of when they're preening themselves over their l337 hex-dump reading skills; it's not about knowing the arcana, it's about solving a problem. If you want to learn and work purely in arcana, then you should study the Kabbalah, or go on Jeopardy, where you can now be beaten by a computer. If you want to get a job done, then use or build the tool that will give you the clearest view of the problem.
KODE VICIOUS, known to mere mortals as George V. Neville-Neil, works on networking and operating system code for fun and profit. He also teaches courses on various subjects related to programming. His areas of interest are code spelunking, operating systems, and rewriting your bad code (OK, maybe not that last one). He earned his bachelor's degree in computer science at Northeastern University in Boston, Massachusetts, and is a member of ACM, the Usenix Association, and IEEE. He is an avid bicyclist and traveler who currently lives in New York City.
© 2011 ACM 1542-7730/11/1200 $10.00
Originally published in Queue vol. 10, no. 1—
see this item in the ACM Digital Library
Follow Kode Vicious on Twitter
Have a question for Kode Vicious? E-mail him at email@example.com. If your question appears in his column, we'll send you a rare piece of authentic Queue memorabilia. We edit e-mails for style, length, and clarity.
Theo Schlossnagle - Time, but Faster
A computing adventure about time through the looking glass
Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, Soheil Hassas Yeganeh, Van Jacobson - BBR: Congestion-Based Congestion Control
Measuring bottleneck bandwidth and round-trip propagation time
Josh Bailey, Stephen Stuart - Faucet: Deploying SDN in the Enterprise
Using OpenFlow and DevOps for rapid development
Amin Vahdat, David Clark, Jennifer Rexford - A Purpose-built Global Network: Google's Move to SDN
A discussion with Amin Vahdat, David Clark, and Jennifer Rexford
Displaying 10 most recent comments. Read the full list heream supposed to write a 20 page report after reading the article by KV. Somehow i ended up reading the comments, and now i don't know what to include in my report. It interesting to note that the comments are more informative than the article.
You would not want to ask that question, would you. Asking that would reduce your future employment options.
George, you are a Glorious Tool (first use of this term). Good luck with your coming election as the ACM secretary/treasurer: http://www.acm.org/acmelections
With your vision, ACM will be on the same road as the IESG: Clouded with prejudice.
There is a fundamental problem here, vendors doing a business lobby right at the IETF table. Patents on standards are very very bad.
Using terms like Glorious Leader in such a fashion otherwise what would be wrong with it and which don't turn up on Google is simply childish.
We put CARP on the same protocol as VRRP. Bute note that the packets can be differentiated. A VRRP implementation must validate the packets fully according to the RFC, ignoring any invalid ones, since they are either noise or a "future version". Without such validation, a VRRP implementation will misbehave when a future variation of the protocol arrives. We created no risk for conforming VRRP implementations. See RFC3117 for the principles behind making such decisions.
Essentially, we had to choose one of these: 1) Give up deploying CARP as a protocol, accepting the IESG refusal of a protocol number. 2) Follow the IETF process: Write up the protocol, hand it to the conflict-ridden VRRP commitee who would make changes to the protocol, and eventually discover a Cisco IPR statement attached to the standard. Robert Barr (Cisco Patent Council) said he believed -- not even having seen the CARP specification -- that CARP would infringe HSRP. IETF would have killed CARP. 3) Reuse the VRRP protocol number, with a clearly incompatible and differentiatable packet format. 4) Allocate a new protocol number (say 222), randomly but unused, without IANA involvement.
We were unaware of any other options. Don't bother inventing other options. It is water under the bridge, CARP is on layer 2 networks everywhere, so we obviously did not choose option 1. You can judge us only for the option we chose, out of the options we saw.
I spent more than a year politic'ing in email with vendors, IESG, and IETF VRRP, and made no headway towards solving the patent debacle -- I exposed myself to lawsuit threads from Cisco. During this time, KAME became aware that VRRP6 had an IPR statement, and deleted their VRRP6 code.
I put OpenBSD and myself out there against restrictive politicies by vendors clearly manipulating standards commitees. You participate in FreeBSD, which has this CARP code in their tree for almost a decade now, and then you attack us!
I believe our choice to put CARP onto the VRRP protocol turned out to be the best for layer 2 networks. In hindsight, it appears better than option 4 described above. VRRP implementations which were doing incomplete validation were fixed; some were found to have holes (HP).
Your accusation of malice without proof, is itself malicious. It is slander. It is far below the standards that ACM holds.
I recommend you read http://www.acm.org/about/code-of-ethics
Displaying 10 most recent comments. Read the full list here