dn42 Explained: Practice BGP Before You Announce on the Real Internet

What is dn42? dn42 is a decentralized, peer-to-peer overlay network where individuals run real BGP routers over encrypted VPN tunnels, using their own private ASN and address ranges. It behaves like a miniature internet with its own git-based registry, IRR-style objects, and RPKI, so you can learn interdomain routing exactly as it works in production without any risk to the public internet.

If you have ever wanted to run BGP but hesitated because a single fat-fingered route could leak into the global routing table, dn42 is built for you. It gives network engineers, students, and homelab operators a full sandbox where the protocols, the tooling, and the workflows are the real thing, but the blast radius is contained to a community of consenting participants. Nothing you announce inside dn42 ever touches the public internet.

This guide covers what dn42 actually is, the address space and ASN ranges it uses, how the registry and peering work, and, just as importantly, what changes the day you decide you want your announcements visible on the real internet. To be clear up front: dn42 is a community project run by volunteers, not a product of ours. We respect it and point people to it constantly, because it is the best on-ramp to BGP that exists.

What is dn42 and why does it exist?

dn42 stands for "decentralized network 42." It is a dynamic VPN network: participants run their own routers, build tunnels to each other, and exchange routes with BGP. There is no central authority handing out connectivity. Instead, every operator peers directly with a handful of others, and the routing mesh emerges from those individual agreements, exactly like the real internet's web of autonomous systems.

The point is education and experimentation. On the public internet, BGP mistakes are expensive and public. A bad announcement can blackhole traffic for thousands of networks, and route leaks make the news. dn42 removes that fear. You can misconfigure a filter, leak a prefix, or break your own routing, and the only people affected are you and the peers who agreed to connect with you.

Why do experienced network engineers bother? Because dn42 is not a toy simulation. You run the same routing daemons used in production (BIRD, FRR, OpenBGPD), you write the same kind of registry objects that RIRs use, and you deal with the same operational realities: filtering, ROA validation, path selection, and troubleshooting why a prefix is not propagating. The muscle memory transfers directly to a job managing a real network.

What address space and ASN ranges does dn42 use?

dn42 deliberately reuses address ranges that will never be globally routable, so there is zero chance of collision with the public internet.

For IPv4, it operates in blocks carved out of the RFC 1918 private space (which reserves 172.16.0.0/12 among others), with its own participant range being 172.20.0.0/14. Other private ranges you may see announced inside dn42 belong to interconnected networks rather than dn42 itself: ChaosVPN, for example, uses 172.31.0.0/16. New participants typically receive a /27 by default, and up to a /26 is available. That is enough addresses to number a handful of routers and services.

For IPv6, dn42 uses the Unique Local Address range. RFC 4193 defines ULAs under the fc00::/7 prefix, with fd00::/8 reserved for locally assigned addresses that are explicitly "not expected to be routable on the global Internet." Participants usually get a /48, and the smallest announceable prefix is a /64. If you want to understand the difference between provider-independent and provider-aggregatable space more broadly, our guide on PI vs PA resources covers the real-world equivalents.

For autonomous system numbers, dn42 assigns from a dedicated block. The primary range is 4242420000 to 4242429999, a self-selected private 32-bit range in use since June 2014. Within that, 4242420000-4242423999 is set aside for end users and 4242427000-4242429999 for sub-allocations. These are 32-bit ASNs that carry no meaning outside dn42, which is the whole point.

How does the dn42 registry work?

Here is where dn42 gets genuinely clever. Instead of a central database, the entire registry is a git repository, hosted at git.dn42.dev/dn42/registry. Every resource, every ASN, every prefix, and every person is a text object committed to that repo.

To claim resources, you fork the repository, add your objects in the correct subdirectories, and open a pull request. Maintainers review it, and once merged, your allocations are live. Commits are signed, and authentication is handled by a mntner (maintainer) object, which is the same concept RIPE and other RIRs use to control who can modify a record.

The object types will look familiar to anyone who has touched an RIR database:

• mntner: your maintainer identity, the key that authorizes changes to your objects
• person: contact details for the human behind the resources
• aut-num: your ASN registration
• inetnum / inet6num: your address block assignments
• route / route6: which ASN is authorized to originate which prefix

This is not a coincidence. dn42's registry is a faithful, hands-on model of the Internet Routing Registry (IRR) system that underpins routing policy on the real internet. Writing a route object in dn42 teaches you the exact discipline you need when you register a real one. If you are heading toward a public ASN eventually, this workflow is directly transferable to the process described in our complete ASN registration guide.

You can query the registry with whois, just like the real thing. dn42 runs anycast whois daemons reachable inside the network, plus web explorers and even bots, so looking up who originates a prefix works exactly as it does on the public internet.

How does RPKI and ROA validation work in dn42?

Modern BGP security relies on RPKI (Resource Public Key Infrastructure) and Route Origin Authorizations (ROAs), and dn42 models this too. A ROA states which AS is authorized to originate a given prefix, so routers can reject announcements that do not match.

In dn42, ROA data is generated directly from the git registry. Tools such as dn42regsrv parse the registry and produce ROA tables in multiple formats, including JSON for RPKI validators and ready-made configuration for BIRD. Public ROA tables are published (for example at dn42.burble.com), and operators can run their own RTR (RPKI-to-Router) server for maximum control.

Your router connects to an RTR server, receives the validated origin data, and classifies every announcement into one of three states:

• VALID: the prefix is covered by a ROA and originated by the correct AS
• INVALID: the prefix is covered by a ROA but originated by the wrong AS, a classic hijack signature
• UNKNOWN: no ROA exists for the prefix

You then write an import filter that rejects INVALID routes. If you have ever wondered how ROA filtering actually feels in a live routing daemon, doing it in dn42 is the answer. The tooling and the concepts are identical to what protects the public internet. When you later get real address space from a sponsoring LIR, ROAs are something you will want handled correctly from day one.

How do you join dn42 and start peering?

The rough path looks like this:

1. Read the wiki and subscribe to the community channels for current best practices, since details evolve.
2. Create your registry objects: a mntner, a person, your aut-num (ASN), an inetnum/inet6num for your prefix, and matching route objects. Submit them as a signed pull request.
3. Find peers. dn42 maintains a public node directory. You reach out to other operators and agree to peer.
4. Build tunnels. Peering happens over VPN: WireGuard is the modern favorite, but OpenVPN and GRE work too. Each peering is a point-to-point tunnel between your router and theirs.
5. Run a BGP daemon. BIRD, FRR, or OpenBGPD exchange routes across those tunnels. You configure sessions, filters, and ROA validation, then watch routes propagate.

Notice that peering in dn42 is an explicitly negotiated, person-to-person arrangement. That mirrors how real peering works: relationships, not automatic connectivity. Learning to ask for a peering session, agree on tunnel parameters, and troubleshoot a session that will not come up is a real operational skill.

dn42 versus public internet BGP: an honest comparison

dn42 is faithful to the real thing, but it is not identical. Understanding the gaps is what makes the practice valuable rather than misleading.

The protocol layer is the same, which is why dn42 is such good practice. What differs is everything around it: real money, real contracts, real trust anchors, and real consequences. dn42 teaches the how; the public internet adds the stakes.

One nuance worth calling out: BGP-4 itself (RFC 4271, published January 2006) is the identical protocol in both worlds. When you configure a session in dn42, you are not learning a dialect. You are learning BGP.

When should you graduate from dn42 to a real ASN?

dn42 is a sandbox, and eventually you may want your announcements to be real. Common triggers include:

• You want to multihome your own network across multiple ISPs with your own address space.
• You are running services (hosting, a small ISP, a research network) that need provider-independent addressing.
• You want a portfolio-visible ASN for professional or business reasons.
• You have simply outgrown the sandbox and want the real thing.

The good news: almost everything you learned transfers. Writing route objects, validating ROAs, configuring BGP sessions, and thinking in terms of AS paths are the exact skills a real deployment needs. If you are unsure what an ASN even represents in the public context, start with our primer on what an ASN is.

What changes when you go public?

Moving from dn42 to the real internet changes three concrete things: your numbers become globally unique, your address space becomes globally routable, and money enters the picture.

A public ASN. You cannot self-assign a real ASN from a git repo. It must come from a Regional Internet Registry (RIPE NCC, ARIN, APNIC, and so on), and unless you become a member yourself, you obtain it through a sponsoring LIR. As a RIPE NCC member and LIR, Via-Registry sponsors ASNs, including for individuals (natural persons), not just companies. Our all-in ASN sponsorship is 130 EUR per year, which already includes the 50 EUR per-ASN RIPE NCC fee under the 2026 charging scheme, with no setup fee.

Real address space. dn42's ULA and RFC 1918 ranges will never be routable. On the public internet you need real addresses. IPv6 leasing with us starts from 40 EUR per year, and IPv4 leasing from 0.50 EUR per IP per month. When you take a /48 from us, it is a PA sub-assignment from our allocation, and the RPKI ROAs are configured automatically at ASN assignment. That means the ROA discipline you practiced by hand in dn42 is handled for you: zero-configuration RPKI out of the gate. If your use case genuinely requires provider-independent IPv6, we also offer IPv6 PI sponsorship.

Real registry work. Your objects now live in an RIR database backed by a contract, not a pull request. The good news is that dn42 already taught you the shapes: aut-num, inetnum, route, mntner. The workflow feels familiar because dn42 modeled it faithfully.

What does going public actually cost?

Here is an honest breakdown. Sandbox practice is free; production carries recurring fees.

For most people graduating from dn42, sponsorship through an LIR is the sensible route. Full RIPE membership only makes sense once your needs justify the 1,800 EUR annual membership plus the 1,000 EUR sign-up fee. For a deeper look at where the money goes, see our ASN registration cost breakdown.

Is dn42 worth it before getting a real ASN?

Yes, and not just for beginners. dn42 is the cheapest, safest, most realistic BGP lab available. You will make mistakes there that would be embarrassing or costly on the public internet, and you will learn from every one of them. By the time you request a real ASN, filters, ROAs, and session troubleshooting are second nature.

The honest summary: dn42 gives you the skills for free; the public internet adds unique numbers, routable addresses, and recurring costs. When you are ready to make that jump, a sponsoring LIR handles the parts dn42 could only simulate, the globally unique ASN, the real address space, and the RPKI anchored to a real trust root. Practice in the sandbox, then go live with confidence.

Official References

• dn42 Getting Started guide: https://dn42.dev/howto/Getting-Started
• dn42 Whois registry service: https://dn42.dev/services/Whois
• dn42 RPKI service: https://dn42.dev/services/RPKI
• dn42 registry (git): https://git.dn42.dev/dn42/registry
• RFC 4193, Unique Local IPv6 Unicast Addresses: https://datatracker.ietf.org/doc/html/rfc4193
• RFC 1918, Address Allocation for Private Internets: https://datatracker.ietf.org/doc/html/rfc1918
• RFC 4271, A Border Gateway Protocol 4 (BGP-4): https://datatracker.ietf.org/doc/rfc4271/
• RIPE NCC Charging Scheme 2026: https://www.ripe.net/publications/docs/ripe-848/

Facts checked July 2026.