If you write public documentation — blog posts, wikis, runbooks — the IP addresses in your examples should come from RFC 5737, not from the private ranges you use at home.
The ranges
| Range | Name | Notes |
|---|---|---|
192.0.2.0/24 |
TEST-NET-1 | The classic. Use for examples. |
198.51.100.0/24 |
TEST-NET-2 | Second example block. |
203.0.113.0/24 |
TEST-NET-3 | Third example block. |
2001:db8::/32 |
IPv6 documentation prefix | The IPv6 equivalent. |
These are reserved by IETF specifically for documentation. They are guaranteed never to be routed on the public internet, and no real network should contain them.
Why not just use 192.168.x.x?
Because RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are real. They are live inside millions of homes and offices right now — very possibly inside the network of the person reading your tutorial.
When you write a config example with 192.168.1.55, a reader copying it onto their own LAN creates a rule aimed at whatever device actually holds that address on their network. That's how firewall tutorials quietly break printers, and how "just follow along at home" produces configs that reference somebody's actual NAS.
Worse: publishing your own real internal addresses (the ones your estate actually uses) in public documentation hands strangers a map of your internal topology. Private does not mean secret — RFC 1918 addresses only protect you if nobody outside learns which devices hold them.
The habit
- Tutorials and public docs: RFC 5737 ranges only.
- Internal runbooks for your own team: your real ranges are fine — that's the point of internal docs.
- If an example IP needs to look "public" (for a NAT or geo-blocking demo), still use RFC 5737 — or an example domain from RFC 2606 (
example.com,example.net).
The test is simple: could a reader paste your example onto their network and have it do exactly what you said, or could it collide with something real? Documentation ranges exist so the answer is always the first one.