Historical note: We implemented the Carrier Pigeon Internet Protocol, RFC1149, with the full scale test performed on April 28, 2001. The following are my lightly edited notes for a talk I gave to the Adelaide Unix user group in October 2005 on the way to participating in the AUUG 2005 conference in Sydney with the first PF tutorial, which in turn is a precursor to The Book of PF (now in its fourth edition).
Note: This piece is also available without trackers but classic formatting only here.
Good evening. My name is Peter Hansteen. I was part of the project group at the Bergen Linux User Group which was the first, and to my knowledge the only group to implement and test Internet communications via avian carriers as specified in the internet draft standard called RFC 1149.
In fact, my laptop - not this one, but a Toshiba which I used every day for another couple of years after the RFC1149 implementation, is probably the only computer in existence which has been pinged via carrier pigeon.
Now the obvious question is, why would anyone want to do such a thing? Well, the purpose of this talk is among other things to answer that question, but first I think it will be useful to briefly explain what an RFC is, and how the Internet standards process works.
This is a fairly technically oriented audience, so I assume you have seen some RFCs and heard references to these documents. Anyway, the RFCs, actually "Requests for comments" are not formally standards, but quite a lot of them would pass for one. A large number of RFCs are either "Current best practices" or "Recommended standards". The standards, recommendations and best practices codified in the RFCs are created and maintained by the Internet Engineering Task Force, which among other things holds conferences three times a year in locations all over the world and acts as the coordinating force for technical matters related to the Internet. You can read all about it at the IETF web site https://www.ietf.org.
The last time I looked (on October 7th, 2005), there 4234 RFCs in total, the last one dated October 2005, while RFC number 1, written by S. Crocker and entitled "Host Software", is dated April 7th, 1969. Dang, it looks like they missed the April's Fool opportunity that year.
Most RFCs are written simply because they are needed, usually to resolve some particular issue. Taken together, they are a large part of the reason why the Internet works and is usable today. Some supersede others, and yet others may pretty much cancel each other out, but taken together, they form the sum of what the Internet is at the specification level.
As I said in the publicity blurb for this talk, there has been quite a lot of experimental stuff on the net since the earliest days, and in some cases the code which implements a proposed standard is ready to the degree that code ever is before the RFC specification is done. In other cases, it takes years for a specification to be successfully implemented and tested. I don't have the complete statistics, but at some point in the future I'm pretty sure that an Internet historian will be able to generate a really nice graph of the data.
Now I can feel you are dying to ask, why did it take so long for RFC 1149 to join the ranks of implemented, if not recommended standards? The document was issued on April 1st, 1990, and the first full scale test of the first implementation took place on April 28th, 2001. Why did it take so long?
To answer that question, we need to take a look at the document itself, dated April 1st, 1990. The heart of the specification is what you find in the "Frame Format" section which states
"The IP datagram is printed, on a small scroll of paper, in hexadecimal, with each octet separated by whitestuff and blackstuff. The scroll of paper is wrapped around one leg of the avian carrier. A band of duct tape is used to secure the datagram's edges. "and
"Upon receipt, the duct tape is removed and the paper copy of the datagram is optically scanned into a electronically transmittable form."
That sounds easy, doesn't it? Any hacker would have the necessary ingredients, which are
- at least two computers (check)
- at least two printers (check)
- at least two scanners (check)
- and
- enough carrier pigeons homed on where the computers, printers and scanners are located.
The last bit is the tough one. That, and of course, if it isn't already mind-numbingly obvious, it was all a joke. The first clue is the date, April 1st. There are several other RFCs date April 1st in various years, and most them were intended to be serious, but they also include such gems as RFC 3514 from April 1st 2003, which specifies how and when to set the "evil bit" for network packets.
That one, if I remember correctly, was in fact implemented the same day in FreeBSD-current, which could then again boast to be the most RFC compliant operating system out there. Looking at RFC 1149, it is pretty obvious that it is nowhere near having any practical value whatsoever. Almost any other way to transfer network packets you can think of will be faster. But the specification is remarkably clear and well written. I remember reading RFC1149 for the first time as an appendix to some TCP/IP training material i was translating in 1993 or 1994. After a few grins, I remember thinking that it could probably be done.
So it was a fairly famous document when we decided to do an actual implementation. The Bergen Linux User Group had resumed activity in the spring of 2000 with regular meetings scheduled for the last thursday of every month except summer and Christmas break months June, July and December.
The core of organizers have tended to meet at my office for planning activities most Thursdays. We would have a more or less formal meeting, planning the next few meetings, talking about possible activities and speakers, and so on. Just around the corner from where I work was an Irish bar, "The Harp", that is to say Irish themed and stocking Guinness stout as well as the regular Norwegian Ringnes pilsner beer. That's where we would usually go for a few beers after we were done with the planning bit.
The idea of actually
implementing RFC 1149 probably first came over beers at The Harp.
This was around the time when most of the serious planning activity in
BLUG was about Linux kernel uberhacker Alan Cox' visit, which was
scheduled for lat April 2001. We thought that Alan would be a major
attraction by himself, but we also thought we needed something
spectacular in order to attract attention and get people to turn up at
the meetings. So somebody mentioned April first RFCs, and since the
idea seemed a good one the next morning too, we decided that RFC1149
was the one, if we could only find pigeons. We were surprised how
easy that was. Typing "brevduer bergen" into a web search engine
(probably google) turned up the web site of a pigeon racing club in
Bergen, with enough contact information for us to make contact.
The first RFC1149 Birds of a feather session took place at Svein Arne Rosendal's house in suburban Bergen on the evening of march 6th 2001. The minutes of that session is available on the web. Basically we were three BLUG people, Karl Magnus Kolstø, Vegard Engen who ended up writing the code and myself. We were able to persuade the pigeon people that it would be a great idea to participate in the project, and they went on to list a few likely candidates from among the club members.
The idea was that it would be better if the two pigeon homes were rather close together, simply because a flying time could become a factor. I think it took only a few days before they had located two pigeon racers who lived within reasonable range of each other. I think the "as the bird flies" distance was around three kilometers, across the small mountain Løvstakken. The peak of Løvstakken is 477 meters above sea level, but the most likely flying route for the pigeons would take them from an elevation of roughly 150 meters up to perhaps 300 then down to around 50 meters above sea level for the outgoing packets and of course the other way around for the return traffic.
We set the date and time, and went on to planning the other parts of Alan's visit - these included feeding the penguins at Bergen Aquarium, a fjords sigthseeing day, the Thursday user group meeting with Alan giving a talk, and finally the pigeons test. Vegard wrote pigeonware in late March or early April.
Now for the technical details - Linux kernels version 2.4 and later feature a TUN/TAP device interface which makes it relatively easy create applications such as pigeonware which handles network traffic via a userspace daemon.
The pigeonware README file lists the package requirements:
- Linux kernel v2.4.x with the Universal TUN/TAP Interface as a module. - GOCR (http://jocr.sourceforge.net) - Printer supported under Linux - Scanner supported under Linux - Pigeons - Some luck
What we used were Vegard's laptop and mine, both Toshibas, and both
running Debian GNU/Linux. The printers were HP LaserJet clones, I
forget which exact makes, the scanners were Agfa USB scanners which
worked flawlessly from the moment they were plugged in. On my
machine, I needed to do a dist-upgrade from stable to testing and a
more recent kernel than the stock Debian one. I remember some
dependencies needed to be resolved by hand, but it did work out in the
end.
Now we had had some serious discussion of what kind of traffic we wanted to test with. Would not sending an email message to delivered by pigeon be an appropriate test, for example? Well, to set up a full TCP/IP connection for an SMTP session, with all handshakes and responses, we calculated it would take roughly 25 network packets - that is 25 - pigeons before we start transferring the actual message. So after a bit of discussion we decided that a ping session, all ICMP, would be sufficient to prove that the technique worked. Ping packets are small, too, so we wouldn't need to fiddle with oversize MTUs or anything.
This is one of the actual packets we generated during a test run:
45 00 00 54 00 00 40 00 40 01 20 A7 0A 00 03 02 0A 00 03 01 08 00 FC 36 84 6B 01 00 CF 15 E7 3A CF 09 06 00 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37
This is from the pre-pigeon dry run testing at my office. We tested the setup, by plugging it all in except the pigeons, disconnected the computers from all other networks, ran the setup scripts and then initiating a ping session. It would take a few seconds for the first page to be printed. To simulate real world conditions, one of the other volunteer helpers would take the sheet of paper, circle the table a couple of times before handing it off to be scanned. The packet was scanned at the destination machine, and after a few moments the return packet would be printed.
Some pictures from the preparatory testing (courtesy Vegard Engen)
The man from the pigeon racing club had indicated a filling station which would be a good place to meet at 10:30, giving us a reasonable amount of time to drive people and equipment to the two pigeon homes and set up in time for the test scheduled for 12 noon. While at the filling station, Vegard in vain tried to explain the project to one of the national TV networks. In fact, as the conversation went on, it sounded to us (who heard only one part of course) that the poor soul at the other end grew more frustrated and confused the more information he was given.
Arriving at the first pigeon home (Bråtet Terrasse), at first nobody was home. This lead to a slight anxiety, almost to the point where various plan B options were considered, when the man we had been waiting for turned up. Setting up the main base with Vegard's laptop, a scanner and a printer started almost immediately, and a smaller group headed for Lyngbøveien to set up the satellite base -- the place to be pinged.
Setting up in Lyngbøveien was a matter of only a few minutes, and the satellite crew ran a couple of test packets saved from the night before to check that the setup was still working. Noon passed, and -- OK, it felt a bit like cheating -- we rung the main base via GSM phone to find out if the first packet had been sent. Not yet, we were told, the documenting took a little more time than exptected.
Several more mobile phone calls followed, relaying information about the number of pigeons sent and the rough location of the largish flock they had joined. After a little more than an hour, a pigeon turned up, only to land at the top of the roof (Kjell's house is a three-story affair) and proceeding to clean the odd wing feather.
Kjell made several attempts at getting the bird to find its way to the pigeon den, and finally succeeded. At last, the initial packet had arrived. The tape was rather sticky, and the strip of paper had been rolled, then flattened a bit, making the optical character recognition somewhat unreliable. We were to discover that hand smoothing (say, with the help of a ruler or even the edge of a table), then attaching the strip of paper to a full A4 sheet of paper before placing it on the scanner improved character recognition significantly.
The next four packets arrived simultaneously within minutes of the first one, leading to some congestion in the scanning queue. When the fourth packet had been sent, we were startled to hear intensive flapping of wings.
The two remaining carrier pigeons had managed to escape without being fitted out with a payload, and we unexpectedly found ourselves in a NO CARRIER condition.
Two more packets arrived, but we were unable to respond. Nothing left to do but unplug and start packing. Our ride arrived after a little while, and after thanking our host, we set off to unload the equipment at the office and returning some of it to the owners. The participators headed in different directions for a couple of hours, with a plan to reconvene at Håvard's to help Alan clean out the tax-free quota. Suffice to say, the combined efforts of several people got us most of the way there.
Vegard's rfc1149 writeup was published Sunday afternoon, and a slashdotting made our previously ~200 hits a day web aquainted with the feeling of more than a million hits on the Monday. Number of hits has been tapering off after that, but stayed in the hundreds of thousands per day for the next couple of weeks.
Soon after the event, Eric Raymond's Jargon file's The Meaning of ‘Hack’ section was updated with a description of the event, naming the implementation "a wonderful hack story for the new millennium".
We also got some attention in the IT oriented press internationally and even mainstream media such as the BBC ran stories about the event. My own favorite is still the Salon item. As far as we are aware, no Norwegian language publication of any kind ever carried a story about this somewhat odd innovation.
Vegard went to the Internet Engineering Task Force conference later in the same year, and received a commemorative plaque on behalf of the group:
There were even some art projects that referenced our implementation, and I think even some that reused the pictures that were available on the BLUG RFC1149 web. (An archived copy of the original site can be found here).
The notes in full prose form end there. I was likely in a hurry to catch a plane, but I mention (as I do in the slides) that we had at least thought of some followup work:
Future developments
* more implementations
needed to get on the Standards track
* Interspecies handoff protocols - relay runners?
In 2011, I wrote a short commemorative article, RFC1149: Ten Years of In-Flight Internet (also here) to note the ten year anniversary, where I noted that
The CPIP WG activities have proceeded at a more leisurely pace in recent years. In 2005 I went to the AUUG 2005 conference to do an early version of the PF tutorial, and en route I made a presentation in Adelaide about the project (slides and accompanying notes are still avaliable).
We're still looking for independent, interoperable implementations, though. Preferably on other free operating systems besides Linux. If we can entice our old pigeon partners to participate, we're more than willing to arrange for interoperability tests.
The world needs this to be on the IETF Standards Track.
Soon after the ten years mark, we did some re-enactments, with people (mainly children) acting as packet carriers, but I have been unable to find any resources about these events available on the web.
Again, independent implementations for other free operating systems would be most welcome, and the original implementers are still available and willing to participate in any interoperability tests.
The implementation of the Carrier Pigeon Internet Protocol, RFC1149, 25 years later is © 2026 Peter N. M. Hansteen (published 2026-04-25)
You might also be interested in reading selected pieces via That Grumpy BSD Guy: A Short Reading List (also here).
![Screenshot of part of a mail bounce message, saying ' peter.hansteen@gmail.com
host gmail-smtp-in.l.google.com [2a00:1450:4025:402::1b]
SMTP error from remote mail server after pipelined end of data:
550-5.7.1 [2a03:94e0:182c::1 19] Gmail has detected that this message is
550-5.7.1 likely suspicious due to the very low reputation of the sending
550-5.7.1 domain. To best protect our users from spam, the message has been
550-5.7.1 blocked. For more information, go to
550 5.7.1 https://support.google.com/mail/answer/188131 a640c23a62f3a-b842a23243csi674652166b.80 - gsmtp'](https://nxdomain.no/~peter/blogpix/likely_suspicious.jpg)
Posts
