It's a great way to explore routing technologies and safely experiment with your own AS, running the same protocols as the "real" Internet, just in private space.
If you do get set up, give me a shout (https://markround.com/dn42), I'd be happy to peer with you if you want to expand beyond the big "autopeer" networks :)
It's been fun explaining to our cloud engineers that BGP is pretty useful in AWS. Most had never touched it after they got their CCNP/CCIE. My networking cred went up a bit.
Its one of those things that there needs to be strong consumer demand for, or it will just never happen tbh.
From our perspective, what we want more than anything in the universe is to never do NAT or DNS ever again. I would much rather maintain a billing system indicating you rent a small block of IPV6 space, with a nice little static route, over maintaining never ending NAT and DNS logs for the benefit of police forces who cant shit without collecting every micron of data. But NAT is basically security these days, and theres a negative driver in exposing customer routers directly to the internet (in that, if it even supports v6 its likely to be rooted) Customers will leave if telcos do things properly, and theres literally zero reward for being nice about it.
The modems they provide handle it without needing anything special from the customers. The devices get IPv6 addresses from this prefix, and are firewalled by default. It's pretty simple so I'm not sure what could go wrong there.
Most ISP do not have such pure goals, as to protect the global routing tables ;)
When you get PI addresses your LIR/ISP just passes your data on to the RIR.
I just want a way to do public-key based discovery. I'm not sure if wireguard + DHT would do though as it'd also mean that it's easy to track your PK (and maybe you through your devices/services announced with PKs).
Maybe you can announce your IP in a neat encryption scheme that adds some privacy without increasing costs too much?
Anything in your private network (even if it goes over public internet) should be encrypted and locked up anyway. Something like Wireguard or Nebula only needs a few (maybe just one) publicly accessible address. Inside the overlay network, it's easy to keep IP addresses stable.
Anything public-facing likely needs a DNS record, updatable quickly when the IP of a publicly accessible interface changes (infrequently).
What am I missing?
How does BGP actually detect a link is down? Keep alive default is 30s but that can be changed. If you set it to say one second, is that wise? Once a link is down, that fact will propagate at the speed of BGP and other routing protocols. Recovery will need a similar propagation.
Depending on where the link is, a second can be a "life time" these days or not. It really depends on the environment what an appropriate heart beat interval might be.
Also, given that BGP is TCP based, it might have to interact with other lower level link detection protocols.
It can get a bit hardware dependant but getting <50ms failovers from software based BFD in BIRD or FRR is fairly easy, and I've tested down to < 1ms before with hardware based BFD echo. ~50ms is the point at which a user making a traditional VOIP call won't notice the path switch.
You can get NIC's for computers (like most Nvidia/Meallanox or higher end Broadcom/Intel NIC's that do hardware BFD, and its obviously included in higher end networking kit.
You then link the BGP routes to the health of the BFD session for which that path is the next hop, and you get super quick withdrawls.
The bigger problem, and where BGP multihoming is most handy, is it's just so much easier to get a holistic in+out failover where nothing really changes vs in DNS where it's more about getting the future inbound stuff to change where it goes. E.g. it's a pain to break an active session because the address had to change, even if DNS can update where the new service is quickly.
Using the wrong route to get the packet in your general direction still gets you the packet as long as it hits an ISP along the way that got the update.
We could fully drain traffic from a transit provider in <60s with a withdrawal with all of the major providers you get at the internet exchanges. If you weren’t seeing that your upstream ISPs may have penalized you for flapping too much and put in explicit delays.
<1 second was normal for hard link down events or explicit withdrawals. Anything above that was waiting for some BGP peer timeout or some IGP event.
If your ISP is taking longer than 1 second to propagate your change, you’ve been put in some dunce protection box.
I found some data from an oldish post by benjojo https://blog.benjojo.co.uk/post/speed-of-bgp-network-propaga... which confirm various tirr 1s do propagate updates across their networks very fast (<2ish seconds) while others certainly do not. Notably, Level 3 (now Lumen) is the largest BGP presence by prefix count and was the worst tested in the list - starting to apply at ~20s after to finishing at ~50s after. This was for announce specifically, which should be the clearer case.
I do agree it should be simpler, but it is accessible to individuals today.
You can have your own PI bloc and move it between ISPs if you so desire. You effectively own the bloc.
Highly recommended for those interested
https://media.ccc.de/v/why2025-9-how-to-become-your-own-isp https://youtube.com/watch?v=raHBq0rUdJQ
Why disable all offloading? It's not explained anywhere.
Just running bird on my VPS to announce my routes to the upstream over a private link.
The market is tight, but nowhere near the point where it was 4-5 years ago. Big cloud providers already bought enormous amounts of IPv4 while many regional ISPs and colocation providers went out of business.
There is no real pressure to buy IPv4 except for brand-new companies to get their initial /24 or /23 to start. Everything else is optional.
It cannot be used commercially and should be in the ‘spirit’ of amateur radio. Unfortunately there’s also a bit of a backlog it seems (a couple of months) right now.
They also offer simpler ‘turn-key’ wireguard tunnels too for things like Web SDR setups.
For BGP direct announce in practice it seems to be in the spirt of non-commercial ‘self learning and experimentation’ which is what a lot of legislatures around the world do use as their base definition for the ‘amateur’ in amateur radio. So I guess much like having slices of radio frequencies reserved for it, we’re lucky there are slices of address space reserved for this.
My supervisor one day rushed into the bullpen and proclaimed that he had registered SEX.ORG, and presumably the only reason was to squat it awhile and then resell it for thousands. [Squatting and speculation were, in fact, quite legal and wise moves at that point in history, especially with a high-demand 6-character site!]
Personally, I discovered the registration process and forms for domain names and network numbers were fairly straightforward. I had seen a Usenet post where someone explained that you just had to write a description of your company, its structure and annual meetings, finances, etc. So I completely made up a fictional company and described those things in my application.
Hey presto, I was now the "owner" and "admin" of cthulhu.com and a corresponding 192.0.0.0/3 Class-C network. Now my coworkers at the ISP were savvy enough to arrange for the DNS servers to answer for their vanity domains. But having no appreciable homelab, or BGP peering of my own, my DNS domain and Class-C Network both languished, until ultimately they were reclaimed in a sweep of unused space by IANA and InterNIC.
I have been unable to recall the exact numbers or find them in a search, but I know that its moniker was related, such as "CTHULHU-NET" or something.
I went on to legitimately register under the .ca.us domain on behalf of my home network and my roommates. cthulhu.com has long been handed over to someone who uses it.
https://rscott.org/OldInternetFiles/network-contacts.1996061...
I had named it "HEARTLAND" rather than a Cthulhu-related name, which was hindering my searches. I had also asked Gemini and it hallucinated a historical record which it was unable/unwilling to link.
The network was: 192.160.182.0/24
ARIN still has the history: https://whois.arin.net/rest/ip/192.160.182.0?s=192.160.182.0
My original assigned user handle was: RE229 (a prime number, very on-brand)
My Netcom email address and a San Jose phone number are enshrined in the record. Don't bother contacting me through those! Interestingly, if you spell out the phone number, it ends in "NET", but does not spell anything compelling in its entirety.
So if this is really still assigned to "me" as boss of "my company" I suppose nobody else has ever announced it. It has no BGP behind it. In fact, 192.160.0.0/16 has no BGP at all. That is a huge swath of space to be vacant.
So, in 34 years since its registration, no BGP announcement, no ASN has ever been associated with this Class-C, and it still "belongs to me", unpaid, un-rented? It boggles my mind. I had expected that it was easier to lose an unused IPv4 network than to lose a domain name from back in the day.
Now there is a lot of crazy contact information that is so, so old. It is credible but I barely recall even having some of those phone numbers. There's an email address at cts.com. Which appears to be utterly defunct now but it was a San Diego bboard run by "Bill Blue". I distinctly recall a lot of Usenet posters using "crash.cts.com" and it was a "shell account" provider. It would've been in-character for past-me to sign up there at some point. Some point, I don't know.
So it says they last attempted to contact me 16 years ago. Did they send a letter in the USPS? Did my family receive nothing? So weird. If I literally wrote to them with that return address, would they validate me?
I literally have no idea how I could even use a /24 network today. My ISP wouldn't accept it. I can't exactly run BGP from a Chromebook or Netgear router at home! I suppose the only way to use it would be on a VPS service? Would the VPS announce an old-school "personal" network?
When ARIN contacts you, it's through email. They send an email with a confirmation link, so that probably bounced.
You can definitely announce BGP from a VPS with some providers. I have been doing this for years. Vultr will do it. However, they will validate (through email) that you "own" the block.
My recommendation is you first contact ARIN and see if you can "recover" contact info associated with the class C.
There are some restrictions around legacy blocks that predate the existing of ARIN. For some reason, they cannot reclaim them easily. So they just sit there...
I'm still holding my early 90's "class C" and have it routed to my home network. It is legacy space, I never signed the ARIN RSA, so it remains free.
I am always very curious why these operations exist. ISPs for the very specific niche of hobbyists who want to run ASNs.
Can this tunnel be avoided somehow? If I have to choose between owning my prefix and having 1500 MTU, I'd probably take the latter: MTU issues are so annoying to deal with, and MSS-clamping doesn't solve all of them.
The whole point of BGP is to influence your routing tables. This fundamentally makes very little sense to do when you have a bunch of routers whose routing policy you don't control between you and whoever you're speaking BGP to. eBGP is just TCP and supports knobs to run over multiple hops (so up to 255), but at that point you can't really do anything with the routing information you exchange because the moment you hand the traffic off, the other party can do with it how it pleases. Also, very few people have enough public IP addresses for this, and on the Internet you obviously can't route RFC1918 space. Therefore, you need tunnels, so that you can be one hop away even if the tunneled traffic is traversing the Internet, and so that you can reach peers that let you announce whatever IP space you want.
The other thing you can do, of course, is to just do the same thing internal to your lab. You can absolutely stand up multiple ASN at home. I'd even argue that if you really want to learn BGP, this is a great way to do it, especially if you use two different platforms (say, FRR on FreeBSD peering with a cheap Mikrotik running RouterOS). That way you learn the underlying protocol and not a specific implementation, which is something that is very hard to undo in junior network engineers that have only ever been exposed to one way of doing things.
That's different from some of the goals outlined in the article, but if your goal is to learn this stuff rather than have provider-independent IP space (which even for home labs isn't very valuable to most people), doing it all yourself works fine.
If your goal is to learn this stuff join dn42, the global networking lab, instead of wasting money with real allocations.
I haven't used Wireguard before, but I believe if you force the wg interface MTU to 1500, things will just work. I use IPSec where the solution would be to use something like link-layer tunneling that, ironically, adds another layer of encapsulation to the equation. Most tunnel solutions don't directly support fragmentation as part of their protocol, but you get it for free if they utilize, e.g., UDP or other disjoint IP protocol for transport and don't explicitly disable fragmentation (e.g. by requesting Don't Fragment (DF) flag).
If I were to do this (and I keep meaning to try), I might still lower the MSS on my server(s) just for performance reasons, but at least the tunnel would otherwise appear seamless externally.
fee schedules FYI
- ARIN 2026 PDF: https://www.arin.net/resources/fees/images/2026feeschedule.p...
- RIPE 2026 : https://www.ripe.net/membership/payment/
Enthusiasts, trainees and small orgs are paying a lot more with RIPE.
Your ARIN link is broken.
It's basically $275/year to have an AS and some PA assignment with no intermediary LIR. In Europe, you have to pay €1800/year without an ASN included. Each resource is billed separately. If you go with a middleman (another LIR) you usually have to pay 200€+ (with taxes) for 2 resources (ASN and PI space)
No such thing. PA by definition is a slice of your LIR's address block.
A PA block is just part of a LIR's block that they give you permission to use, so I doubt you could keep that if they went out of business, but maybe RIPE has a procedure for it.
Outside of that, I have another couple of VPSes I use for experimenting with routing and fail over that are closer to my location. The VPSes are connected to my home network and each other over Wireguard.
€75 per assignment / sponsored resource €50 per ASN assignment
So in your case it's only €50 for the AS-object but your LIR needs to allocate their LIR base fee costs (which includes the IPv6 PA that they assigned to you), also infrastructure, the VM, support.
I really like the couple of LIRs that are very active in supporting one-person-multihoming setups, but IMHO RIPE should directly do that at a low entry fee. RIPE has also education/training offerings for LIRs and that would increase the knowhow and reach of RIPE. Most home lab enthusiasts will apply the gained knowledge in their job, at customers and bring new customers to RIPE.
When I first made the ARIN or RIPE LIR decision a few years back, ARIN required a $500 registration fee for an ASN. That was a few years of LIR fees right there. I felt it was worth the risk for the savings with a hobbyist setup.
Otherwise, getting to know the power of FreeBSD is awesome. Thanks for creating the blog!