2001, a DB8 odyssey
How come all the talk about IPv6 comes with illustrations like 2001:db8:1234:abcd::321? When we eventually adopt IPv6, is some person or company going to find all the students, hackers and IT novices hitting the same network addresses just because they were mentioned in the IPv6 text books and cheat sheets? Will the eventual owners of these addresses be like current SlashDot victims, overloaded with unexpected traffic?
No. In fact, you are encouraged to use the 2001:db8 block of IPv6 addresses in your documentation (and possibly some illustrative code) precisely because it is reserved for that purpose. RFC 3849 explains that “the Asia Pacific Network Information Centre (APNIC) allocated a unicast address prefix for documentation purposes”, so we can safely use these addresses. In fact, it is likely that IPv6 hardware and software will explicitly filter out these addresses, the same way that local IPv4s are filtered to prevent external routing.
In fact, good old-fashioned IPv4 also has addresses reserved for documentation purposes. According to RFC 5737 the addresses 192.0.2.*, 198.51.100.* and 203.0.113.* (known as TEST-NET-1, 2 and 3) are reserved for documentation.
Furthermore, in the case of the DNS, RFC 2606 tells us that the TLDs .test, .example, .invalid and .localhost are all reserved, together with the domains example.com, example.net and example.org, which are reserved by IANA. None of these domains will (or should) be resolved by DNS servers, and they cannot be assigned to anyone.
What if you want to test some code that has example.com domains? The DNS server should not resolve this name because it officially cannot have an IP address (v4 or v6). Out of curiosity, I added example.com to my hosts file, mapping it to one of the reserved IP addresses and everything worked fine. This begs a question: how many other systems out there will accept names/addresses that are supposed to be reserved for documentation only?
Among the tests to be performed are:
- DNS servers that permit reserved TLDs to be configured.
- DHCP servers that will assign reserved IPv4 addresses.
- Web servers that will accept reserved host names.
- Network stacks that will attempt to route reserved addresses.
- Tools that will attempt to transmit/receive traffic involving reserved ranges.
So far, I have not been able to determine if there are reserved addresses for MAC documentation. This may have been overlooked. Also, there is no reserved SSID for wireless networks, which would have been a good idea as using it as the default would have prevented so many WiFi hacks that have plagued users for years, because it would have forced people to choose another SSID during installation, instead of keeping the well-known (vendor-specific) defaults.
Network enquipment that erroneously routes reserved addresses are just creating big security holes. This also applies to the routing of local addresses (e.g. 192.168.*.*), which should never go beyond your immediate network. Most vendors have taken care in this area, but it’s still a concern to the paranoid.
Let’s hope that future technologies remember to reserve some “play space” and that implementors respect these decisions.
Categorised as: Networking, Technology