ACM

Communications of the ACM

Home/Opinion/Articles/The Network Protocol Battle/Full Text

Kode Vicious

The Network Protocol Battle

By George V. Neville-Neil
Communications of the ACM, April 2012, Vol. 55 No. 4, Pages 27-28
10.1145/2133806.2133816
Comments (1)

View as: Print Mobile App ACM Digital Library Full Text (PDF) In the Digital Edition Share:

yin and yang symbol composed of computer mice — Credit: Sashkin / ShutterStock.com

Dear KV

I have 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 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 would not 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 does not conflict with anything on my networksuch as UDP or TCPand 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 email campaign to get a properly assigned number?

Waiting

Dear Waiting

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 many readers have just spit coffee on their screens, because none of them can remember the last time I complimented a writer in 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 are not getting any more space anytime soon.

The protocol field can be seen as a commons for the Internet, so let me tell you a tragedy, and one that did not 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 is not particularly important what the protocol does, but it is 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 companiesCisco and IBMboth 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 non-legal terms this means 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 is a bit like talking to a four-year-old child. When you explain checkers to your niece, she might decide she does not like your rules and follows her own rules. You humor her, she is 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 upset, because this person would obviously be trying to confuse, 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 was not 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 is 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 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 upends the checkers game in frustration. She runs away crying, and you are 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.

Dear KV

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 am not really sure why. Wouldn't a tool make more sense?

Hexed by Dumps

Dear Hexed

I am not sure how many variations on the "Tools are Useful" theme I will eventually write, but clearly my message has not penetrated to the depth I would like. In part, I think the problem is that geeksand I include myself in this groupenjoy the feeling they know thingsin particular, things they think others do not 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 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 instance, as someone who looks at a lot of network packets, I can tell you the example shown in Figure 1 is an IPv4 packet, and I can then scan through it to find the IP addresses and other bits I need to know to diagnose what is wrong with a host's network connection.

Compared with Figure 1, though, I would rather read the example shown in Figure 2. Sure, Figure 2 is also gobbledygook to the average person, but it is far easier to read and understand for the professional who is trying to get a job done. It is 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 are preening themselves over their 1337 hex-dump reading skills; it is not about knowing the arcana, it is 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.

Author

George V. Neville-Neil ([email protected]) is the proprietor of Neville-Neil Consulting and a member of the ACM Queue editorial board. He works on networking and operating systems code for fun and profit, teaches courses on various programming-related subjects, and encourages your comments, quips, and code snips pertaining to his Communications column.

Figures

Figure 1. One view of an IPv4 packet.

Figure 2. An easier-to-read view.

Comments

Marko Schuetz-Schmuck

April 17, 2012 07:25

Dear KV,

I agree with the statement "Tools are Useful", but knowing and being able to read a low-level representation goes boyond "preening themselves over their 1337 hex-dump reading skills".

All tools operate in specific contexts with very specific assumptions, e.g. as a standalone program that intercepts network traffic or reads a file that stores such traffic.

It is often helpful to be able to identify and/or parse the same kind of information outside of the context that the tool requires. Using the example of the IPv4 packet this might be when debugging a core dump and finding the hexdump of [[Figure 1] http://cacm.acm.org/magazines/2012/4/147357-the-network-protocol-battle/fulltext#F1 ] in some buffer. In my experience it is often that being familiar with the low-level representation is enormously helpful as it allows one to spot suspicious states and to investigate behavior in contexts where the dedicated tool is not available.

"Tools are useful", but so is just /seeing/ through the representation.

Sincerely,
Marko

Displaying 1 comment