4.1 KiB
CRAPRNIAC: Completely Ridiculous Amateur Protocol for Radio Node IP Address Configuration
Status of this Memo
This document describes version 0.1a of CRAPRNIAC, a protocol designed to facilitate IP network bootstrapping over very slow amateur radio links (e.g., VHF AX.25 at 1200 baud). It is published for whatever unexpected practical utility it may have. Distribution of this memo is unlimited.
1. Introduction
Existing service discovery and dynamic host configuration protocols for TCP/IP networks are not ideal for bandwidth-constrained, high-latency, and lossy VHF packet radio environments. CRAPRNIAC addresses this by defining a join-and-configure protocol between a "base station" and one or more "client stations" that aims to cut the chatter.
The goals are to:
- Let a client discover a nearby base station, request an IP address, and join a packet network.
- Bring honor to you and your house?
2. Protocol Overview
CRAPRNIAC defines four primary message types:
| Message Type | Purpose |
|---|---|
| CRAP_BEACON | Base station announces network availability. |
| CRAP_REQUEST | Client requests to join the network. |
| CRAP_ACCEPT | Base station assigns configuration to client. |
| CRAP_ACK | Client acknowledges receipt and acceptance. (optional) |
Messages are transmitted as plain ASCII text using simple pipe-separated (|) fields, allowing easy parsing by humans and computers alike.
The protocol is versioned and extensible to allow for a future in which this is relevant enough for there to be concern over compatibility.
3. Message Format
Each CRAPRNIAC message is a single text string with the following general format:
<PROTOCOL_VERSION>|<MESSAGE_TYPE>|<PAYLOAD_FIELDS...>
3.1 Example Messages
CRAP_BEACON
0.1|CRAP_BEACON|KI5QKX-10|HAMNET-HOUSTON
Fields:
- Base Station Callsign
- Network Name
CRAP_REQUEST
0.1|CRAP_REQUEST|N0CALL-7|HAMNET-HOUSTON
Fields:
- Client Callsign
- Network Name
CRAP_ACCEPT
0.1|CRAP_ACCEPT|N0CALL-7|HAMNET-HOUSTON|44.127.254.12/24|44.127.254.1|44.127.254.1|3600
Fields:
- Client Callsign
- Network Name
- Assigned IP Address
- Netmask
- Gateway IP
- DNS Server IP
- Lease Time (seconds)
CRAP_ACK (optional)
0.1|CRAP_ACK|N0CALL-7|44.127.254.12|OK
Fields:
- Client Callsign
- Assigned IP Address
- Status
4. Base Station Behavior
- Periodically transmit CRAP_BEACON.
- Upon receiving a CRAP_REQUEST, allocate an IP address.
- Respond with CRAP_ACCEPT containing IP configuration details.
- Optionally await CRAP_ACK.
- Maintain a list of active clients and lease expirations.
5. Client Behavior
- Listen for CRAP_BEACON transmissions.
- Send CRAP_REQUEST to desired base station.
- Receive and parse CRAP_ACCEPT.
- Configure network stack accordingly.
- Optionally send CRAP_ACK.
- Periodically rejoin if lease expires or connectivity is lost.
6. Design Considerations
- Make it, despite its name, not crappy
7. Security Considerations
That's what the 'S' in CRAPRNIAC stands for.
8. Other Considerations
- CRAPRNIAC does not prescribe a particular lower-layer protocol, though it is designed with a working AX.25 stack in mind, whether that's a classic serial TNC, a more modern bluetooth doodad, or Direwolf with kissattach creating an ax0 interface. The example implementation used UDP packets over IP over AX.25 until the author realized it needed IP to be up already before it could work. Now it does everything in AX.25 directly.
- CRAPRNIAC will squat on an amateur frequency of the operator's choice.
9. Conclusion
CRAPRNIAC provides a starting point for connecting TCP/IP stacks over slow amateur radio links. By limiting the number and length of transmissions required for negotiation, it offers networking over VHF that works as nice as it smells.
10. Further Development
- Future enhancements may include optional mesh extensions for self-organizing slowness.
- A TLV protocol would be more compact. But why make it more efficient when the transmissions are literally slow enough to read with your eyes?
Author: John Burwell Date: April 2025