If you’ve spent any time at all working with IPv6, chances are that at some point you’ve needed to document or depict a network design or configuration.
If your organization already has an IPv6 Global Unicast Allocation, you might have been tempted to simply use prefixes and/or addresses from this range for such documentation purposes. After all, these addresses and prefix ranges are presumably already familiar to you and your team. And if said design or configuration is going into production, figuring out the actual prefixes and addressing to allocate and use is already a necessary step.
But there are many depiction scenarios where it wouldn’t be desirable to use prefixes or addresses from your Global Unicast Allocation. You might be building a proposed design strictly for initial review and discussion. The use of GUA addressing in such an instance could cause an uninformed reviewer to mistake such a design for a planned or existing deployment with already-allocated production addressing. And even though many more recent GUA allocations to enterprises are large enough to perhaps assign a sufficient dedicated prefix for internal documentation, you might find yourself prefix-space-constrained in some (arguably distant) future, leaving your documentation overlapping with desired production addressing.
Another scenario could be the development of examples for training material or vendor documentation, which often include more generalized depictions of IPv6 networks and protocols. Using GUA addressing for such examples wouldn’t make a whole lot of sense – especially if such examples are to be more generally distributed outside of your organization or by a vendor. Most organizations don’t want to share more information about their IP space than they absolutely must (and for some government agencies, such information is considered sensitive, if not necessarily classified).
So, if using your own IPv6 GUA space is not optimal for these and other reasons, why not just go rogue and squat on some random GUA IPv6 space? And if you have any pangs of conscience you could even use Whois to make sure it hasn’t already been allocated to some other organization. There’s even the roughly 75% of the IPv6 prefix space that hasn’t even been allocated by IANA yet: You could debut some tiny sliver of that vast, unexplored space to the world through your humble IPv6 network examples! /sarcasm
All joking aside, having an IPv6 prefix (or two) dedicated for use with documentation helps avoid some of the suboptimal outcomes described above. And using a formal documentation range communicates more clearly to the (informed) reviewer that such addresses are not intended for configuration and use in production networks.
The first and oldest of the IPv6 documentation prefix is the IANA-defined prefix:
- 2001:db8::/32
IANA, in case you’re not familiar with it, is the Internet Assigned Numbers Authority. They have the responsibility of allocating and maintaining “the unique codes and numbering systems that are used in the technical standards (‘protocols’) that drive the Internet.” These include – among other special IPv4 and IPv6 addresses – the ranges reserved for documentation purposes.
In case you’d forgotten or never knew about the IPv4 documentation ranges, they are defined in RFC 5737: IPv4 Address Blocks Reserved for Documentation and include:
- 192.0.2.0/24
- 198.51.100.0/24
- 203.0.113.0/24
I’ll confess that I wasn’t fully aware of all the dedicated documentation ranges for IPv4 until after I learned about 2001:db8::/32. I suspect that part of the reason these ranges were not well-known to me has to do with how rarely vendor documentation and training material actually used them (at least as far as I noticed). On further consideration, their infrequent use is perhaps understandable. They don’t exactly provide an abundance of address space to depict larger deployments. Which, as we’ll examine, is exactly the problem that befell the first IPv6 documentation range of 2001:db8::/32. But this was far from evident when the prefix was originally defined twenty years ago, in RFC 3849: IPv6 Address Prefix Reserved for Documentation.
In those early days of very limited deployment of IPv6, standards for how much IPv6 space should be used were a bit vague. In 2001, RFC 3177: IAB/IESG Recommendations on IPv6 Address Allocations to Sites, recommended “the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.” Flash forward to 2011, RFC 6177 IPv6 Address Assignment to End Sites concedes that “a one-size-fits-all recommendation of /48 is not nuanced enough for the broad range of end sites and is no longer recommended as a single default.”
But for the sake of our analysis, if we start with a /32 of documentation space and assume a /48 per site, we would seem to be covered for any network up to 65,536 sites in size. In other words, more than enough documentation space appears available. But this apparent sufficiency hinges on also assuming a somewhat oversimplified network – perhaps one that is contained within a single autonomous system or as part of a single autonomous system.
From a perspective that focuses on address planning, one of the most powerful benefits of the abundance of IPv6 prefix space and addressing arises from the ability to summarize (and enforce security policy) on easily recognized nibble-aligned prefix boundaries.
As a result, network structure within an organization (perhaps a single AS) will tend to use more of the overall prefix space available in an allocation. In the earlier days of IPv6, when only the largest organizations received a /32, all internal planning and documentation could likely be accomplished with the 2001:db8::/32 prefix. But such allocations have organically grown as organizations have recognized the benefits of nibble-aligned planning and summarization. Regional Internet Registry (RIR) policy has followed suit, most impactfully perhaps in the initial shift by RIPE to a minimal assignment of a /29 for most organizations. A prefix of this size immediately exceeds the capacity of the original /32 documentation range. And of course, Service Provider WAN documentation and training examples depicting multiple ASes were always constrained by this limited documentation space, given that each AS is likely to use at least a /32 or larger.
Fortunately, after much discussion within the IETF, a new IPv6 documentation range request was recently formalized in an RFC, with IANA allocating it soon after: RFC 9637: Expanding the IPv6 Documentation Space.
The new documentation range is:
- 3fff::/20
Note that there are, at the time of publication, only 30 allocations of a /20 or larger made by RIRs to requestors (i.e., 1 /16, 1 /17, 3 /19s, and 25 /20s). Given that the remaining 99.96% of RIR allocations are /21 or smaller, this documentation range should prove adequate for most examples – especially intra-AS ones.
If you’re tasked with documenting or modeling inter-AS examples with prefixes sized at the larger end of the existing GUA space, you might end up having to get a little creative (and bend a few rules) outside of the available /20.
A Cautionary Tale
In my excitement to use the new documentation prefix, I immediately built several examples from it for some training materials I was working on at the time. I wanted to model an enterprise with a /32 allocation and proceeded to use the following example prefix: 3fff:9d00::/32.
See what I did there? Well, I didn’t until I was more than halfway done with a video that I subsequently had to rerecord. 😬
If I had been paying closer attention to proper nibble alignment, I would have noticed sooner that the prefix I wanted was 3fff:9d0::/32. It’s not the first time (nor will it be the last) that the drop-the-leading-zeros address concatenation rule bit me in the behind.
So always try to keep in mind that the 3fff::/20 prefix includes the first nibble of the second hextet. Taking the extra step of highlighting the significant nibbles of the prefix can help visually reinforce this:
- 3fff:0000::/20
Here’s a list of the first nibble-aligned prefixes derived from the /20:
- 3fff:0000::/24
- 3fff:0100::/24
- 3fff:0200::/24
- 3fff:0300::/24
- 3fff:0400::/24
- 3fff:0500::/24
- 3fff:0600::/24
- 3fff:0700::/24
- 3fff:0800::/24
- 3fff:0900::/24
- 3fff:0a00::/24
- 3fff:0b00::/24
- 3fff:0c00::/24
- 3fff:0d00::/24
- 3fff:0e00::/24
- 3fff:0f00::/24
And here’s what the prefixes look like when they are “zero compressed” according to the IPv6 address representation standard:
- 3fff::/24
- 3fff:100::/24
- 3fff:200::/24
- 3fff:300::/24
- 3fff:400::/24
- 3fff:500::/24
- 3fff:600::/24
- 3fff:700::/24
- 3fff:800::/24
- 3fff:900::/24
- 3fff:a00::/24
- 3fff:b00::/24
- 3fff:c00::/24
- 3fff:d00::/24
- 3fff:e00::/24
- 3fff:f00::/24
Strange Vendor Documentation Examples
Be aware that vendor documentation, configurations, and examples using IPv6 addressing often use invalid addresses. Trying to reverse engineer the definition of valid documentation ranges using only vendor examples would be difficult if not impossible.
One recent example from a major vendor used the following prefixes:
- 2001:1000::/64
- 2001:2000::/64
These ranges are part of the overall global unicast allocation (GUA) of 2000::/3 but of course fall outside of the actual available documentation ranges of 2001:db8::/32 or 3fff::/20.
The same example also includes prefixes that would appear to be from the ULA range (RFC 4193 Unique Local IPv6 Unicast Addresses):
- fde0:1000::/64
- fde1:1000::/64
But these prefixes do not follow the guidance from the RFC for proper ULA prefix and address construction. While the eighth bit of the prefix is set to 1 to indicate that the prefix is locally assigned, the next 40 bits (represented by e0:1000:0000: and e1:1000:0000:) are supposed to be randomly generated. This of course is quite common with how lots of folks configure and use ULA (fd00:1::/48, etc. or even fc00:1::/48 where “c” is the 8th bit and is not set to 1 which represents currently undefined IPv6 address space according to the RFC).
The next two prefixes from the example are even more egregious:
- ffea:0000::/64
- ffeb:0000::/64
These are squatting in the IPv6 multicast range but are being used in the example as if they were unicast prefixes! Never mind the documentation ranges: these don’t even conform to basic valid IPv6 address architecture.
Here’s hoping vendors put in the effort to clean up their documentation and that they take advantage of the new documentation range while doing so. In the meantime, take that new range for a spin the next time you need to document an IPv6 network!
