RFC 2322

Management of IP numbers by peg-dhcp 🧷✨

Okay bestie, RFC 2322 is a protocol for handing out IP addresses using wooden clothes-pegs 🧷 and I'm obsessed. It's dated 1 April 1998, so yes, it's an April Fools' RFC, but it's also weirdly serious underneath. 💅

Here's the title block, all in one place:

• Number: RFC 2322 🌸
• Title: Management of IP numbers by peg-dhcp
• Authors: K. van den Hout (HvU/HIP-networkteam), A. Koopal (UUnet NL/HIP-networkteam), R. van Mook (University of Twente/HIP-networkteam)
• Category: Informational
• Date: 1 April 1998
• Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates. 🦋

---

Status of This Memo 📝

This memo gives information to the Internet community. It is not a standard of any kind, and it doesn't specify an Internet standard. You can distribute it as much as you like, no limits. 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

Introduction 🧚

Okay so this RFC describes a protocol for dynamically handing out IP numbers on field networks and small events that don't really have a clear organisation running them. 🎀

It can also provide some fixed extra fields that are the same for every client, like the netmask and even autoproxyconfigs. And it doesn't depend on any particular IP stack, so it's giving flexible. 💅

History of the protocol. 🕰️

The peg method for assigning IP numbers was first used at the HIP event (http://www.hip97.nl/). HIP stands for Hacking In Progress, a huge three-day event where more than a thousand hackers from all over the world got together. The event needed a TCP/IP LAN with an Internet connection, and visitors and participants could bring their own computers and hook them up to the HIP network. 🖥️✨

While the team was prepping for HIP, they ran into a real problem: how do you assign IP numbers at the scale they were predicting without ending up with duplicate numbers or skipped numbers? 😭 Because the expected computers came with so many different IP stacks, a software solution like a Unix DHCP server probably wouldn't work in every case and could create unexpected technical problems. 💀

So they needed a way to centrally administer IP numbers and hand them out to people for their computers. After some discussion, someone suggested using wooden clothes-pegs, and it was a genius move. Pegs have these advantages over other methods:

• cheap 💸
• a peg is a 'token' and represents one IP number, which makes the status of the IP number (allocated or not allocated) visible 👀
• a peg can be clipped to a network cable, giving a very clear view of where a given IP number is in use 🔥

Credit for the original idea of using wooden pegs goes to Daniel Ockeloen. 👑

The server. 🎪

The server can look like a lot of different things. At HIP it was a big tent in the central field where all the activities were. It can also be a small table in the corner of a terminal room. 🏕️

The server can hand two parts to the client: the peg, and a paper with additional fields that are fixed for the site the server is running for. We'll describe both. 🫶

The peg. 🧷

The IP number is written on the peg. The text on the peg can be described with the following BNF:

Total ::== IP | Net

IP ::== num.num.num.num | num.num | num

Net ::== num.num.num/mask | num.num/mask | num/mask

num ::== {1..255}

mask ::== {8..31}

The Net method of writing larger nets is an optional part of the protocol, so it doesn't have to be implemented. If you do implement it, it requires more administration at the server (see below). 📋

The short versions of the IP number with only 1 or 2 chunks are meant for large servers, where writing the whole number on the peg is just boring and time-consuming. They require the prefix to be mentioned on the additional field paper, but that can be produced in more convenient ways. It is not recommended to work with more prefixes. It's better to write more numbers on the peg and use a smaller prefix. 🙈

If the network you're numbering is rather large and some kind of subnetting has to happen, you can give the pegs from the different subnets different colours. This has proven to be a very convenient way at HIP. 🌈💖

The additional vendorfield paper. 📄

This part is for information that's fixed for the whole site. It can be implemented as small printed notes handed out with the peg, or as a large paper billboard hung somewhere convenient where everybody can read it. 🪧

The information can be described with the following BNF:

Network ::== num.num.num.num

Netmask ::== num.num.num.num | num

Gateway ::== num.num.num.num | num.num | num

Proxy ::== num.num.num.num:port | num.num:port | num:port

Paper ::== Network Netmask Gateway Proxy | Network Netmask Gateway

num ::== {0..255}

port ::== {1..65535}

The paper and the peg are of course one part. If two numbers are used on the peg, two numbers are used on the paper. 🧩

Because the information is fixed, it can be produced with mass-production methods like printing and copying. 🖨️

The IP-repository 🧺

Because of the nature of the peg, the repository can be super simple. It's just a clothes-line with all the pegs that are ready to be handed out attached to it. If you work with different subnets, it's convenient to group the pegs for each subnet by colour. 🌸

On large networks where nobody really knows how many IP numbers are needed, you can make a first set of pegs in advance, and keep a paper record of which numbers already have pegs made for them. If you use the net extension on the pegs, numbers handed out that way can be tracked this way too. 📒

Issuing IP-numbers. 🎟️

The pegs and the IP numbers are issued at the server to the client. Normally the client has to visit the server in person. Depending on how secure and controlled you want the process to be, the client either has to ask a responsible person for a peg, or they can just grab one from the store themselves. 🧍‍♀️

If someone could apply for a network range, and the net extension isn't used, coat-hangers can be prepared with sets of pegs attached to them. 🪝

The vendorfields paper doesn't have to be issued with every peg. It's only needed when wanted. 📄✨

Reclaiming and reusing IP-numbers. ♻️

It's not easy to implement a TTL in this protocol. One obvious TTL is the duration of the event, after which the IP numbers aren't valid anymore. ⏳

However, if a client decides it doesn't need an IP number anymore, it can bring the peg back to the server. 🔙

At that point, the server should decide what to do. If it wants to, it can bring the peg back into the pool by attaching it to the clothes-line again. 🧺

If the server isn't manned (the client has to help themselves), the only thing possible is for the client to just place the peg back into the pool. 🙃

The client side. 💻

The best spot for the peg is clipped to the network cable near the NIC of the device that needs an IP number. This makes a clear visual connection between the device and its IP number, and it's an easy way to see which IP number is allocated. 👀🔥

Transferring the IP information from the peg and the additional vendorfield paper note into the IP stack settings is done by a human. A person reads the information from the peg and the additional information, then types it into the configuration of the IP stack they're using. This transfer is not completely free of corruption or loss of the information on the peg. 😬

A certain amount of knowledge about how IP settings work is also assumed on the part of the person doing the transfer. 🧠

Other information on the vendorfield paper note has to be transferred into the settings of specific application programs. 📱

Use with other protocols 🕊️

This protocol could be combined with avian carriers, as described in RFC 1149, to hand out IP numbers remotely. 🐦💖

At the first avian carrier, the peg is clipped to the carrier's leg after the additional vendorfield paper has been rolled around it. 🪶

The remote site can take the peg when the avian carrier arrives and use the information on it. 🎉

This part of the protocol is still experimental and requires some additional research on topics like the weight of the peg and loss of the peg or the whole carrier. 💀

Security Considerations 🔐

Okay, security is serious, so let's talk about it. 🥹

Some remarks about security can be made. Pegs are small and can be lost. When that happens, the IP number that was lost can't be used anymore, because someone else can find the peg and use the information on it. 😨 But once the peg is attached to a network cable, the chance of losing it is minimised. 🧷🔒

All the information on both the peg and the additional 'fixed' fields on the paper record is plain text, and anyone can read it. Private information should not be exchanged through this protocol. 🙅‍♀️

On the client side, all sorts of clients exist and cooperate freely. Because clients are human and transfer information from the peg to the IP stack by hand, the information can be misinterpreted, which could cause network trouble. In the field test at HIP this became perfectly clear when someone mixed up the numbers and used the address from the default router as their IP number, which made the network useless for a while. 🫠💀

Authors' Addresses 📮

Koos van den Hout
Hogeschool van Utrecht / Expertisecentrum Cetis
P.O. box 85029
3508 AA Utrecht
The Netherlands

Phone: +31-30-2586287
Fax:   +31-30-2586292
EMail: koos@cetis.hvu.nl


Andre Koopal
UUnet Netherlands
P.O. box 12954
1100 AZ  AMSTERDAM
The Netherlands

Phone: +31-20-4952727
Fax:   +31-20-4952737
EMail: andre@NL.net


Remco van Mook
Van Mook Consulting
Calslaan 10-31
7522 MA Enschede
The Netherlands

Phone: +31-53-4895267
EMail: remco@sateh.com

Full Copyright Statement ⚖️

Here's the legal stuff, kept complete. 💜

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ✨