I encountered a funny situation this past week while deploying IPv6 on a tunnel interface. I realized that when you use 10 for the most significant digits in an IPv6 address it does not mean that is the tenth address in that network. We are trained to think in terms of decimals from the very beginning of our education as children. Breaking out of that mindset and thinking in hexadecimal is an essential skill for operating a network in an IPv6 world. When starting to deploy IPv6 it is important to start to learn to think in Hexadecimal.
As you may know, IPv6 addresses are 128 bits in length (compared to 32-bit IPv4 addresses). Because IPv6 addresses are so long they are typically written in 8 segments or "chunks" of 4 hexadecimal digits. Therefore, an IPv6 address looks something like this.
Typically the first 4 segments (64 bits) represent the network prefix and the last 4 segments (64 bits) represent the node/interface identifier. Do you remember the old days of using IPX or AppleTalk where there is a network number and a node number? Most IPv6 networks use this /64 prefix length, regardless of whether the network contains 10 hosts or 1000 hosts.
IPv6 addressing plans typically focus on the fourth segment of this IPv6 address. That is because the first 3 segments represent the /48 address that was assigned by the IPv6 Internet service provider to the customer. For example, the service provider would assign 2001:db8:1111::/48 to the customer for use in addressing their entire network.
Note: I am using IPv6 documentation prefix (2001:0DB8::/32) here in this article to discuss the topic while preserving the identities of the organizations involved.
Last week when we were configuring a tunnel interface we were using a /126 prefix length. The reason a /126 was being used is because only two network devices were required on that prefix (one network device on each end of the tunnel). Even though we have plenty of IPv6 addresses to burn I think of the old adage "waste not, want not". I am an avid recycler and it doesn't sit well with me to waste an entire /64 when all we need is a much smaller. However, I should mention that you should really avoid using a /127 prefix on IPv6 networks. This would be the IPv4 equivalent of using a /31 subnet.
As it turns out, our plan was to use 2001:db8:100:200:300::9 for one end of the tunnel and to use 2001:db8:100:200:300::10 for the other end of the tunnel. Can you see what is wrong with this picture? If you can then you are far quicker than I was at this moment.
When we configured our end of the tunnel to the service provider the tunnel interface came operational. The service provider's tunnel interface also became active. However, we couldn't ping across the tunnel to each other's IPv6 address.
It took us about 30 minutes to realize that 2001:db8:100:200:300::0010 was not the correct address and we should have been using 2001:db8:100:200:300::000A. When we write out the address with the leading zeros it is easier to see our mistake. We were stunned when it finally sank in that A was the hex equivalent of 10 in decimal. The hex equivalent of 0010 in decimal is 16. As soon as we configured the one end of the tunnel with the "A" address all the routing became fully operational.
Now, those of us troubleshooting this were all experienced network engineers and we know how to perform IPv4 subnetting with speed and precision. This was also not any of our first rodeos when it came to IPv6 either. In the end we were all a little embarrassed when we realized that we weren't thinking in hex. This was a funny example of how thinking in decimal is so ingrained in our brains and how we will really need to pay attention to hexadecimal address notation when deploying IPv6. I must tell you that I will never forget this lesson.