2001:db8::/32 in the Wild

If you have ever read some docs or RFCs about IPv6 you should be quite familiar with the 2001:db8::/32 “IPv6 Address Prefix Reserved for Documentation”, RFC 3849. This RFC clearly states how you should handle addresses within this range: “This assignment implies that IPv6 network operators should add this address prefix to the list of non-routeable IPv6 address space, and if packet filters are deployed, then this address prefix should be added to packet filters.”

I was interested whether those addresses are actually used in the Internet. For this purpose I analyzed my firewall logs for 6 months to get an idea. Though it was not that much, I actually got a couple of connections inbound and outbound (!) sourced or destined to those reserved IPv6 addresses.

Note that this post is one of many related to IPv6. Click here for a structured list.

Please note that I have a very limited view unfortunately. I have NOT made a big study about that, capturing all around the world, but only some very few stats from my private lab. Since I am running a couple of services such as authoritative DNS servers, NTP servers (listed in the NTP Pool Project), email servers, a RIPE Atlas probe and classical HTTPS servers, I have at least a couple of dynamic sources/destinations in the Internet that are using my ISP connection.

I logged all IPv6 connections that are either sourced or destined to the 2001:db8::/32 range for 6 months, November 2017 to April 2018. All connections were made through my Palo Alto Networks PA-200 firewall, which forwarded all logs to a syslog-ng server (since the storage on the firewall itself does only suffice for a couple of days). All those connections were blocked by the firewall since there is no reason to allow them as they won’t succeed anyway.

Results: It’s Happening

During this 6 month period I got four different sets of connections:

  • 3x incoming ping sessions (= 3 different sources) to the RIPE Atlas probe, each with 3 or more echo-requests. Sources:
    • 2001:db8:beba:cafe::1:2
    • 2001:db8:beba:c0ca::1:2
    • 2001:db8:acad:1::ff
  • 1x incoming ping to the NTP server (ntp3.weberlab.de). Source:
    • 2001:db8::5002
  • 2x incoming NTP requests to the NTP server (ntp3.weberlab.de). Sources:
    • 2001:db8:1:0:685c:8437:b74b:b437
    • 2001:db8:ff00:3f:d898:469f:2b95:162e
  • 4x outgoing DNS sessions to 3 different destinations:
    • 2001:db8::21e:c9ff:fee8:8459
    • 2001:db8::204:23ff:fec9:f26a
    • 2001:db8:1:ffff::ca81:1b87
facepalm” by ▓▒░ TORLEY ░▒▓ is licensed under CC BY-SA 2.0

So, what do we have here? Three incoming connections, either ping or NTP requests. That is: (1st) Some clients/servers out there have 2001:db8:: addresses configured, (2nd) they are using them for outgoing connections and (3rd) none of the involved ISPs is blocking them. They get fully routed to my lab.

More interesting from my point of view are the last sessions, in which I had outgoing (!) connections to 2001:db8:: addresses as well. Wait, what? Those connections are destined to DNS servers, sourced from my own iterative caching server. Unfortunately I cannot tell which DNS servers or domain names are related to that since I did not capture the complete traffic.

That is: Some DNS server admins in the Internet are using 2001:db8:: addresses for their authoritative DNS servers! Oh oh, these are for sure not only lab installations, but misconfigurations or misunderstandings of the IPv6 address usage at all.

Looking at the addresses, you can see some classical EUI-64 based host IDs (::21e:c9ff:fee8:8459), some semi-random host IDs that are eventually from Microsoft devices (::685c:8437:b74b:b437), and some other manually configured IIDs such as “2001:db8:acad:1::ff” or “2001:db8::5002”.

Conclusion

Yes, the “reserved for documentation” IPv6 prefix 2001:db8::/32 is in fact used in the Internet for test and/or productive usages. This is definitely not intended. However, it is not that crucial at all. Those connections won’t ever succeed and no real traffic will flow. That is: no security leakages or stuff like that. Anyway, it’s some kind of noise that is unintended. (Though you could DDoS someone with those addresses.) Upper layer protocols will find there way through legacy IP (if configured as dual-stack hosts) such as timeouts for DNS or happy eyeballs for HTTP (RFC 8305).

Raw Data

In case you’re interested, here are the raw syslog messages that I grepped with weberjoh@jw-nb10-syslog-mirror:/var/log/firewalls/2003:de:2016:120::f01:443$ cat */*/* | grep 2001:db8 > ~/2001-db8-raw :

 

Trivia

Note that there are legacy IPv4 address ranges that are reserved for documentation as well, RFC 5737 “IPv4 Address Blocks Reserved for Documentation”. I am using them sometimes, though it’s much more common to use the RFC 1918 private addresses for documentation as well. (Hopefully you’re not using 1.1.1.1 in your docs.) At least for sample addresses that are placed in the Internet (e.g., at MS Visio charts/drawings), those ranges are fine:

  • 192.0.2.0/24 (TEST-NET-1)
  • 198.51.100.0/24 (TEST-NET-2)
  • 203.0.113.0/24 (TEST-NET-3)

Featured image “Beep Beep – Bison at The Wilds” by Lorne Sykora is licensed under CC BY-NC-ND 2.0.

Leave a Reply

Your email address will not be published. Required fields are marked *