JoyfulReaper / kgivler on DN42 — multi-edge hobby network with public VPS POPs and a residential FreeBSD POP
This is my little corner of DN42 for networking experiments, weird services, and whatever else I feel like running.
AS4242420425 is a multi-edge hobby network with public VPS edges and a residential FreeBSD POP. No SLA, just networking experiments and things I find interesting.
AS4242420425172.20.220.48/28fdf0:e12c:5528::/48joyfulreaper.dn42
HTTP API
· classic QOTD: qotd.kgivler.dn42:17
Clanker, ScopeCreep, and Wurstcase are public VPS edges. hbg1 runs as a residential FreeBSD POP in Harrisburg, PA. Wurstcase is the Frankfurt POP. The network uses a four-router full-mesh iBGP core over dedicated WireGuard links.
Clanker provides controlled full-table IPv4 and IPv6 transit to Baragoon, RoutedBits, and MDR. ScopeCreep provides the same experimental model to iEdon and Kioubit. hbg1 has an external eBGP session with PuduNet NY01 using own-prefix-only export and a 5 Mbps cap in each direction. Wurstcase peers with Silverha DE1 in Frankfurt using controlled full-table transit. Transit paths use dedicated alternate routing tables and policy routing, with interface rate limits where configured.
Detailed topology, peers, routing policy, and peering requirements are documented below.
qotd.kgivler.dn42:17
(nc qotd.kgivler.dn42 17; TCP/UDP port 17)
fdf0:e12c:5528::90, Gemini/TLS on TCP/1965)
Clearnet resource note: Some
services exposed on DN42 still reference resources hosted on the
normal Internet, such as CDN-hosted CSS or JavaScript, images,
fonts, APIs, or other external assets. Visiting a
.dn42 service may therefore cause your browser or
client to make additional clearnet requests. A DN42 hostname does
not currently guarantee that every resource used by the page
remains inside DN42.
Clanker and ScopeCreep run on GreenCloud VPS, where they host routing, public services, monitoring, and some of the other nonsense linked from this site. Wurstcase is hosted separately by Servitro in Frankfurt, Germany. GreenCloud has worked well for the kind of small Linux VPS infrastructure I run here, and the pricing has made it practical to keep multiple locations online without spending much.
The GreenCloud and Servitro links above are affiliate links. I may earn a commission if you sign up through them.
Four core routers require six direct iBGP relationships. hbg1's DN42 WireGuard tunnels are independently capped at 5 Mbps in each direction per tunnel.
| Network | ASN | Location | Edge | Routing | State |
|---|---|---|---|---|---|
| RoutedBits | AS4242420207 |
Newark, NJ | Clanker | Full table / controlled transit; 50 Mbps cap | Established |
| Baragoon | AS4242421732 |
New York, NY | Clanker | Full table / controlled transit; 50 Mbps cap | Established |
| MDR | AS4242420401 |
New Jersey (useast01) | Clanker | Full table / controlled transit | Established |
| HEADSCARF175 | AS4242420842 |
Piscataway, NJ | Clanker | Provider role to us; own prefixes out | Established |
| iEdon | AS4242422189 |
Dallas, TX | ScopeCreep | Full table / controlled transit; 50 Mbps cap | Established |
| Kioubit | AS4242423914 |
Los Angeles, CA | ScopeCreep | Full table / controlled transit; 50 Mbps cap | Established |
| MOE233 | AS4242420253 |
Las Vegas, NV | ScopeCreep | Valid routes in; own prefixes out; eligible alternate path for iEdon transit | Established |
| PuduNet | AS4242422227 |
New York, NY | hbg1 | Valid routes in; own prefixes out; no transit; 5 Mbps cap | Established |
| Silverha | AS4242420762 |
Frankfurt, Germany | Wurstcase | Full table / controlled transit; 50 Mbps cap | Established |
For controlled-transit peers, third-party routes
learned from the ingress peer are excluded from that peer's return
routing view, while directly originated prefixes remain reachable
over the direct session. BIRD sorted tables and
secondary on provide alternate export paths where
available. ScopeCreep may forward transit through iEdon, Kioubit,
MOE233, or the Clanker core according to its alternate routing
views. Wurstcase normally provides a controlled-transit edge through
Silverha in Frankfurt. Other external sessions, including PuduNet on hbg1,
remain own-prefix-only exports unless explicitly configured otherwise.
Manual peering requests are open. WireGuard is the preferred tunnel transport. MP-BGP over IPv6 link-local with Extended Next Hop is preferred where supported.
Please have valid DN42 registry objects and ROAs. Low-latency North American peers are especially welcome, but they are not a hard requirement.
hbg1 peering: hbg1 is a residential FreeBSD POP on a 200 Mbps home connection. Peering there is intentionally small and experimental: external peers are capped at 5 Mbps in each direction. hbg1 can initiate WireGuard sessions outbound to a peer's reachable endpoint, including over IPv4. The BGP session itself uses IPv6 link-local addressing and can carry both IPv4 and IPv6 DN42 NLRI. Because hbg1 is a residential POP, do not assume that it is directly reachable for inbound WireGuard on every public address family. hbg1 does not offer general transit by default, and the residential connection carries no SLA or uptime promise.
I generate a fresh WireGuard keypair per approved peer. There is intentionally no single public WireGuard key shown here. After I approve a request, I create the peer-specific interface and return my public key, UDP port, and link-local details.
Submitting this form does not automatically configure anything. Requests are reviewed manually. No automatic WireGuard, firewall, BIRD, or route changes are made.
For my sanity, peering requests are globally limited to one submission every 15 minutes. If someone beat you to it, wait a bit and try again.
Basic request metadata is stored locally for peering administration. Peering submissions are stored in SQLite and may trigger a private ntfy notification. There are no third-party analytics or advertising services.