Summary

  • RFC 2322 described a physical allocation system for a temporary event network: one wooden clothes-peg represented one IP number, and the unissued pegs hung together as a visible pool.
  • The token exposed allocation state, but a person still issued it and copied the address and shared settings into a computer. The RFC’s own field report says a participant mistook the default router’s address for their own, interrupting the network for a time.

RFC 2322 is not a DHCP standard. Published on 1 April 1998 as an Informational memo, it describes “peg-DHCP” for field networks and small events without a clear administrative body. Its account starts at Hacking In Progress, a three-day 1997 gathering in the Netherlands. Organizers expected a crowd to bring varied computers and wanted a TCP/IP LAN with Internet access. They worried about duplicate or skipped numbers and about a software server working differently across unfamiliar IP stacks. The RFC records that motivation; it does not provide a test showing that ordinary DHCP failed.

The proposal made one part of administration tangible. A peg stood for one address. Unissued pegs on a clothesline were the pool; a peg clipped beside a computer’s network cable showed where an address had gone. Colored pegs could distinguish subnets. For a short-lived event, staff could issue a peg at a tent or table, while a less controlled setup could let participants take one themselves. A paper card or notice supplied common values such as the network, mask, gateway and proxy. The participant then typed them into the computer and relevant applications.

That last step matters. Peg-DHCP did not configure the interface, negotiate a lease or verify who held the address. It moved allocation bookkeeping out of a server’s hidden state and into an object people could see and move. The person remained the protocol adapter between a peg, a paper note and an operating system. RFC 2322 says that transcription could lose or corrupt information—and gives a concrete example: at the event, someone entered the default-router address as their own address, making the network unusable for a period.

The lifecycle was equally local. A client could return a peg to the server’s pool when finished. If no attendant was present, the client had to put it back. The event’s end could act as a rough time-to-live, since addresses would no longer be valid after the gathering. That is not the same as DHCP’s lease exchange, where a client and server communicate allocation, renewal, rebinding and expiry. The contrast is not “manual bad, automatic good”; it is visible custody and human judgment versus protocol state and message exchange.

The RFC’s security section is plain about the boundary: a lost peg might be found and reused, and both the token and shared paper were readable. It says private information should not be exchanged this way. The peg represented an allocation; it did not prove a person’s identity or authenticate their right to use an address. Its remote-delivery aside—clipping the peg to an avian carrier—is expressly left experimental, not a deployment claim.

RFC 2322’s historical value is therefore narrower and more useful than its joke premise suggests. It turned a hidden pool into visible, inspectable state for a bounded setting, while making the human handoff impossible to ignore. The same visibility that helped an organizer notice whether a number was in use could not prevent a mistaken number from being typed into a machine.

Sources