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 the way it works in production without any risk to the public internet. In September 2026 the network counted more than 1,500 autonomous systems and 1,700 prefixes, according to the dn42 wiki.

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 point people to it because it is where most operators run their first BGP session without consequences.

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. If you run Docker on the same host, move its default address pool out of 172.16.0.0/12 first, or your containers will not reach dn42 (dn42 FAQ).

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. Generate a random /48 as RFC 4193 describes: other networks connected to dn42 use fd00::/8 too, so the registry cannot rule out a clash. 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. They sit inside the private-use block 4200000000-4294967294 that RFC 6996 reserves; our guide to private ASN ranges covers the other private blocks.

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. Browsing it or opening a pull request needs an account on git.dn42.dev; anonymous visitors see a sign-in page. The registry explorer shows the same objects without one.

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. Before submitting, run the registry's own scripts (fmt-my-stuff, check-my-stuff, check-pol) and squash your changes into one signed commit.

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 AS number record
• 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 you feed your router either from one of the public RTR (RPKI-to-Router) servers listed on the wiki or from your own, for example StayRTR loading the burble JSON. There is no certificate hierarchy: the table is built from the route and route6 objects themselves. In the RIPE Database a route object and a ROA are two separate records you keep in step; see how to create ROAs in RIPE.

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

• VALID: a ROA covers the prefix and the origin AS matches
• INVALID: a ROA covers the prefix, but the origin AS is wrong or the prefix is longer than the ROA's max-length, the classic hijack signature
• UNKNOWN (NotFound in RFC 6811): no ROA covers 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 validator states and the filter logic are the same as on the public internet; only the trust anchor differs. When you later get real address space from a sponsoring LIR, ROAs are something you will want handled correctly from day one. Once you announce public space, the RPKI checker shows whether a prefix and origin validate.

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. The Peer Finder on the wiki suggests operators with low latency to you; you then contact them on IRC, by e-mail or on the mailing list. Some networks run self-service autopeering pages that set up a session without manual approval (23 were listed on the dn42 wiki in September 2026).
4. Build tunnels. Peering happens over tunnels: WireGuard, GRE, OpenVPN, IPsec or Tinc. Each peering is a point-to-point tunnel between your router and theirs.
5. Run a BGP daemon. BIRD (the 2.x and 3.x branches are both maintained in 2026), FRR, or OpenBGPD exchange routes across those tunnels. You configure sessions, filters, and ROA validation, then watch routes propagate.

Most dn42 peering is still agreed person to person, which is how real peering works too. 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. A public ASN you obtain later can also be used inside dn42, with proof that you hold it and a clean split between dn42 and Internet routes (dn42 FAQ). 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. The RIPE NCC also requires the network to be multihomed (ripe-679): the request names at least two upstream or peer networks, so a single-homed node does not qualify. Proposal 2026-01, in the drafting stage in September 2026, would drop that test for a first ASN held with a prefix the RIPE NCC assigned directly; it is not policy.

As a RIPE NCC member and LIR, Via-Registry sponsors ASNs for individuals (natural persons) as well as companies through our ASN registration service. It costs €130 per year as of September 2026: our €80 fee plus the €50 per-ASN charge of the RIPE NCC Charging Scheme 2026 (ripe-848), passed through at cost. Two years can be prepaid at order for €234, with 20% off the second year of our fee and the RIPE NCC line unchanged. Your name and postal address then appear in the RIPE Database; there is no privacy proxy for a registry object. If you want to compare sponsors first, the ASN sponsorship price comparison lists nine of them with sources.

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 at €40 per year for a /48 (as of September 2026). That block 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 you want the block registered to you by the RIPE NCC and portable between sponsoring LIRs, an IPv6 PI /48 costs €300 setup plus €135 per year (€435 the first year), with RPKI through your own End User hosted CA.

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 NCC membership costs €1,000 to join and €1,800 per year in 2026, plus €50 per ASN. From 2027 the fee is €1,894 per year with the first ASN included (ripe-867, adopted at the May 2026 General Meeting). Membership pays off once you need address allocations of your own, and even then new IPv4 is a single /24 after a waiting list (ripe-826). For a deeper look at where the money goes, see our ASN registration cost breakdown.

Is dn42 worth it before getting a real ASN?

For most people, yes. dn42 costs nothing beyond a small server, and what breaks stays among consenting peers. 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.

dn42 teaches the skills for free. A public ASN adds a globally unique number, routable space, a multihoming requirement and a yearly fee, and a sponsoring LIR handles the registry side that dn42 could only simulate: the assignment itself, the real address space and RPKI anchored to a real trust root.

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, sign-in required): https://git.dn42.dev/dn42/registry
• dn42 registry explorer: https://explorer.burble.com/
• 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/
• RIPE NCC ASN assignment policy (ripe-679): https://www.ripe.net/publications/docs/ripe-679/
• RIPE NCC Charging Scheme 2027 (ripe-867): https://www.ripe.net/publications/docs/ripe-867/
• dn42 Automatic Peering list: https://dn42.dev/services/Automatic-Peering