Whether creating training materials, writing technical documentation, or building Proof-of-Concept (PoC) demonstrations—for public courses or for enterprise internal training—we always need example IP addresses.
You might ask: Are there any reserved IP blocks that are guaranteed never to overlap with live production environments?
The answer is yes. The IETF has already defined dedicated blocks across several RFCs. This article summarizes the reserved Unicast address ranges you should be using.
Why Do We Need Dedicated Documentation Addresses?
Randomly picking a public IP address for a demonstration creates a high risk of conflicting with a real-world organization's assigned network. This leaves your audience confused: "Is this configuration universal, or is it a custom setup tailored specifically for that company?"
Bad Example 1: Arbitrarily Using Public IPs
When demonstrating OSPF features, I used to assign `1.1.1.1/32` to a Loopback 0 interface address. However, `1.1.1.0/24` is a live public IP block allocated to APNIC and operated in partnership with Cloudflare. Using it creates confusion over whether that OSPF feature is a standard for everyone or a Cloudflare-specific solution.
Bad Example 2: Using RFC 1918 Private IPs
What about using private IPs, like `10.1.1.1/24` as an example LAN default gateway? The issue persists. Inside a given enterprise, `10.1.1.1` might already be assigned to their internal DNS server. During internal training, attendees can easily confuse your example gateway with their company's actual DNS server.
To eliminate ambiguity, all educational content, technical guides, and PoC demos should strictly use reserved documentation subnets.
The good news is that the IETF has already reserved these exact address ranges for us.
Reserved IPv4 Unicast Address Blocks for Documentation
Per RFC 5737, three IPv4 blocks are explicitly reserved for documentation and educational use. They are:
- TEST-NET-1: 192.0.2.0/24
- TEST-NET-2: 198.51.100.0/24
- TEST-NET-3: 203.0.113.0/24
These ranges do not overlap with public routable addresses or RFC 1918 private space (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`), guaranteeing they will never be mistaken for a live production address.
⚠️Caution: Production networks should never deploy these IP address ranges. Because most routers and operating systems treat them as standard unicast IPs by default, edge network devices should actively block or filter these blocks using Access Control Lists (ACLs) or route policies to prevent accidental routing or leaking.
Reserved IPv6 Unicast Address Blocks for Documentation
For IPv6 environments, two prefix blocks are reserved:
- 2001:db8::/32 (RFC 3849)
- 3fff::/20 (RFC 9637)
Similarly, these prefixes do not overlap with any Global Unicast Addresses (GUA) or Unique Local Addresses (ULA), ensuring complete isolation from production traffic. As with IPv4, production networks must not assign these prefixes and should filter them out at edge boundaries.
One More Thing...
I wrote this post to serve as a reminder for myself. Moving forward, when drawing topology diagrams, writing guides, or building lab examples, I will strictly use these designated blocks.
IPv4 Address Blocks for Documentation:
- 192.0.2.0/24
- 198.51.100.0/24
- 203.0.113.0/24
IPv6 Address Blocks for Documentation:
- 2001:db8::/32
- 3fff::/20
No comments:
Post a Comment
Tip: you can also anonymously comment here.