IPv6 Interface ID Structure

While there are many approaches on how to structure your IPv6 prefix into /64 subnets (blogposts, books, talks) there are only a few hints what you can do with the other 64 bits of the addresses, namely the IPv6 interface identifier or IID. To my mind you can put some (but not too much) logic into those IIDs to a) have some structure for your addresses that b) helps you identifying those addresses when seeing them in logs or anywhere else. Hence it is easier for you to remember the IPv6 address behind a name (forward DNS) as well as the host when seeing the address (reverse DNS).

This post just shows the approach I am using in my lab. You might find it useful or you might disagree completely. Anyhow, feel free to comment your experiences or solutions for that. :D I am wondering why there isn’t much discussion about these IIDs at all. Maybe for some good reasons I am not seeing yet?

The idea to use the IID part of IPv6 addresses for some logic is to have identifiers and unique counters for all devices similar to an inventory, independent of the current IPv6 subnet it is used in.

Host ID Structure in my Lab

The main part is to use the last two hextets in order to reference the type of device “dddd” and the type of service “ssss”. The 5th and 6th hextets are left zero in order to use the abbreviation with two colons. Hence my address look something like this, 3rd line:

For the type of device I am using a single letter (a-f) followed by two digits as a counter. An exception is “d” for appliance in which I am using some more logic for the type of device rather than a mere counter:

  • a: virtual machine
  • b: notebook (b = book)
  • c: hardware server
  • d: appliance (and VMs that are a “virtual appliance”)
    • d01: Cisco ESA
    • d04: Pulse Secure
    • df5: F5 BIG-IP
  • e: infrastructure (switches, routers)
  • f: firewall

For the type of service I am using the TCP/UDP port the device is listening on, such as:

  • 22: SSH
  • 25: SMTP
  • 53: DNS
  • 123: NTP
  • 514: Syslog
  • 443: HTTPS

Exceptions

Of course, no good rule without exceptions. ;D For example, I am operating a couple of stratum 1 NTP servers in which I am using the 7th hextet to include the type of clock source such as DCF-77 or GPS. Or I am running a random number generator at random.weberlab.de (IPv6-only) in which I generated the IID randomly.

Some Examples

To get an idea here are some examples of my hosts:

HostnameIPv6 AddressComment
mail.webertest.net2003:de:2016:110::d01:25Mailserver appliance Cisco ESA: d01
Port: 25
ns1.weberdns.de2003:de:2016:110::a07:53DNS nameserver on VM number 7: a07
Port: 53
lx.weberlab.de2003:de:2016:110::b15:22Linux running on notebook number 15: b15
Port: 22
ip.webernetz.net2003:de:2016:110::a12:443Webserver running on VM number 12: a12
Port: 443
ntp1.weberlab.de2003:de:2016:330::dcf7:123NTP server with DCF-77 receiver: dcf7
Port: 123
ntp2.weberlab.de2003:de:2016:330::6b5:123NTP server with GPS receiver: 6b5 <- kind of funny
Port: 123
ntp3.weberlab.de2003:de:2016:330::dcfb:123Second NTP server with DCF-77 receiver: dcfb <- b for second one
Port: 123
pa-mgmt.weberlab.de2003:de:2016:120::f01:443Firewall management for firewall number 1: f01
Port: 443
esxi03.weberlab.de2003:de:2016:120::c03:443ESXi server on hardware number 3: c03
Port: 443
syslog.weberlab.de2003:de:2016:120::b10:514Syslog server running at notebook number 10: b10
Port: 514

As you might have noticed I am not a big fan of security by obscurity but of reliable firewall rules. ;D Hence I have no problem that I am publishing my real IPv6 addresses here.

Conclusion

I really like it. Especially the reverse DNS functionality. I do not only know my prefix 2003:de:2016::/48 and the subnet IDs such as 110, but also some IIDs such as ::a08:53 or ::dcf7:123.

After some time working with your own prefix and IID structure you can easily identify hosts and services without using reverse DNS zones. At least for some well-known hosts. Compared to legacy IPv4 you can remember your IPv6 addresses even better! This is contrary to the prejudice that v6 addresses are harder to remember than v4 addresses. They aren’t!

Trivia: IPv6 Address Enumeration

By the way: One common project for IPv6 security researchers is the intelligent scanning of IPv6 spaces since you cannot simply scan the whole /64 or whatever subnet length. It seems that there are some projects ongoing since I can see several pings to IPv6 addresses that look quite similar to some of my real used IPv6 addresses. Have a look at this screenshot from my firewall’s traffic log:

For example, the second row shows a destination of 2003:de:2016:119::d01b:25 , while my real server is at 2003:de:2016:110::d01b:25 . Hence they are enumerating the 4th hextet from “110” to “119”, and so on.

Another example: They are pinging 2003:de:2016:110::a12:4c3  while my look-alike address is 2003:de:2016:110::a12:443 , hence they’re enumerating the last hextet. ;) Short discussion at Twitter here.

Further Reading

Some links for further reading:

Featured image “123456789” by Angie Harms is licensed under CC BY-ND 2.0.

2 thoughts on “IPv6 Interface ID Structure

  1. How do you handle a VM used as a webserver with different domains / IPs on it?

    For example VM1:
    2003:de:2016:110::a01:????
    has websites 1,2,3,4 with port 80 and 443 (with redirect from 80->443)
    2003:de:2016:110::???:443
    2003:de:2016:110::???:443
    2003:de:2016:110::???:443
    2003:de:2016:110::???:443

    Best regards,

    Dirk

    1. Hey Dirk,

      yes, that’s a good question. I have not yet had this scenario. Hence not featured in my ideas.
      Just a few quick thoughts:

      – You could omit the 443 in the last hextet and use it as a counter for your domains instead. That is:
      2001:db8::a01:1
      2001:db8::a01:2
      2001:db8::a01:3

      – Or, if you still want to see the port in the last hextet, you could use the sixth hextet as a counter, such as:
      2001:db8::1:a01:443
      2001:db8::2:a01:443
      2001:db8::3:a01:443
      But maybe this is too much logic in there?

      Cheers, Johannes

Leave a Reply

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