Yeah it's very effective. It has a big downside of people losing the pegs and then those addresses are "lost" but all that means is that 2 users can't reliably connect and when they report to IT they will be asked if they had the correct peg. And I guess quarterly do a review for unused addresses that have pegs out and create new ones for lost pegs.
I want to criticize this but I have multiple production environments with no DHCP and the process for provisioning new servers is basically "Guess an ipv4 address and if you pick one that's already in use the build will fail and you can guess again."
This is arguably better which is a little embarrassing.
I did something like this some 22 years ago or so. I can't remember the exact reason why but essentially DHCP was not reliable enough or it caused some issue with the proprietary network hardware my company built and sold. So I built a little "kiosk" (old laptop with an HTML interface to an database) that would give you an IP and a "return by" timer of 12 hours. Before displaying it would ping to make sure the IP wasn't active. Looking at this post I know realize that I could have just bought a pack of clothes pins and saved myself some trouble.
Introduction
This RFC describes a protocol to dynamically hand out ip-numbers on
field networks and small events that don't necessarily have a clear
organisational body.
History of the protocol.
The practice of using pegs for assigning IP-numbers was first used at
the HIP event (http://www.hip97.nl/). HIP stands for Hacking In
Progress, a large three-day event where more then a thousand hackers
from all over the world gathered. This event needed to have a TCP/IP
lan with an Internet connection. Visitors and participants of the
HIP could bring along computers and hook them up to the HIP network.
During preparations for the HIP event we ran into the problem of how
to assign IP-numbers on such a large scale as was predicted for the
event without running into troubles like assigning duplicate numbers
or skipping numbers. Due to the variety of expected computers with
associated IP stacks a software solution like a Unix DHCP server
would probably not function for all cases and create unexpected
technical problems.
It's not a joke if it specifies a procedure to solve a real-world problem.
RFC 2549 is a joke, RFC 1149 is almost a joke (basically a spec for a sneakernet, XKCD What If 31 ), RFC 2324 is mostly a joke but also an example of IoT... and a similar thing goes for all of these:
The XKCD one is interesting, but seems to be missing the transfer to/from the storage medium sent by FedEx.
If I want to move data from my computer to yours over the internet, the internet bandwidth between our devices/networks is the main consideration. If I’m FedExing SD cards or HDDs, I’ve also gotta take into account the transfer times to get the data ONTO those devices.
I wonder how the analysis would fair when taking into account:
Haha this is literally how we used to deal with this at CampZone, a huge LAN party, back in the mid-2000s.
At later editions they just enabled DHCP on the network, I think they didn't at first because they wanted to be independent of DHCP servers. Early editions even had a negligible internet uplink (after all, it was a LAN party). Though later ones had faster uplinks than the thousands of participants could fill.
Talking about Lan uplinks, in the early 2010's I had the joy of working with a 20gb uplink at a small university LAN (the sysadmin got a good amount of free pizza and beers for that one). I spent a large amount of my savings on a 10gb NIC only to find out my hard drive couldn't keep up lol.
I remember in 1993 my uni had no uplink. It was UUCP only (so just polled mail). In 1994 we got an uplink which was 256kbit shared between all sites. Luckily it came in to our facility first (the IT/Tech branch) and was cascaded further so we basically used it all 😜
This is basically how radio controlled models using FM TX/RX pairs were coordinated back in the day, there would be a board with each frequency crystal that you would use for your transmitter, and you'd plop the matching one into your model.
Reason being that if someone was already flying something and you turned your radio on to the same frequency, they would immediately crash.
Can't tell if you're joking, but a Request For Comments is effectively a proposal for how a process should be performed.
Some of them are eventually ratified as internet standards by the IETF.
Plenty of them remain useful as defacto standards even without formal acknowledgement.