Summary

  • Bergen’s 28 April 2001 demonstration recorded four ICMP replies from nine requests; two returning pigeons carried no packet, and the surviving log shows 55% loss.
  • The receiving computer did not finish the job alone: a person unrolled the paper, scanned it, checked the OCR and corrected errors before accepting the reply.

The packet crossed a room before it crossed a network

RFC 1149, dated 1 April 1990, describes IP datagrams carried by avian carriers. Its own status text calls the method experimental and not recommended. The document’s joke is precise about the interface: write each octet in hexadecimal on a paper scroll, wrap it around a bird’s leg, secure it, then optically scan the paper at the other end. The RFC describes a format. It does not show that anyone built one.

In Bergen, the plan became a small working chain. Minutes from a March 2001 meeting assign research on pigeon transport and attachment to one part of the group; the Bergen Linux User Group took responsibility for the computer interface. Members were to find scanners and investigate OCR on Linux. The announced public demonstration was set for 28 April, in cooperation with a local pigeon club. This is evidence of preparation by a named group, not proof of routine service.

What the surviving log can prove

The retained transcript starts at a Linux point-to-point interface, tun0, with endpoints 10.0.3.2 and 10.0.3.1. It records an MTU field of 150 and the command ping -i 900 10.0.3.1. The output lists four ICMP replies, with sequence numbers arriving in the order 0, 4, 2, 1. Its final count is nine requests sent, four received and 55% packet loss. The recorded round-trip times range from about 3,212 to 6,389 seconds.

Those numbers belong to one session. They establish that this particular setup returned some packets to the host’s ping process. They do not measure a general pigeon network, explain every missing request, or establish a repeatable service level. Nor did the bird itself hand a decoded datagram to Linux. The write-up says the paper was removed and unrolled, scanned, then reviewed by a person who checked and corrected OCR mistakes before the packet was accepted.

The group’s narrative says the planned interval was seven and a half minutes. Its terminal transcript records -i 900. The two records do not reconcile that difference, so the schedule should remain an open question. The narrative also says six pigeons returned, two without packets after a cage was left open. Four replies appear in the log. The write-up ends by saying the group was waiting for other implementations before interoperability tests could take place.

A demonstration is a narrow rung on the ladder

RFC 2549 later extended the same subject to quality of service; RFC 6214 adapted it to IPv6. Their status labels still matter: RFC 2549 is Experimental, and RFC 6214 is an Informational Independent Submission. The update chain extends the published joke, but it supplies no evidence that the Bergen setup interoperated with another implementation or became a deployed network.

The useful historical result is smaller. Bergen’s report and transcript expose the actual boundary between a specification and one observed implementation: a Linux interface, a paper carrier, a scanner, OCR and human correction. The evidence reaches a specific running system and stops before adoption. It is a demonstration with a visible receive path, not a standards transition.

Sources