IPv6 is the next generation of IP addressing. In this video, you’ll learn about IPv6 addresses and methods of connecting IPv4 and IPv6 networks using tunneling, dual-stack routing, and NAT64.
Our current estimates put the total number of devices connected to the internet somewhere around 20 billion with a b. One of our ongoing challenges associated with this huge rise in number of devices is that IP version 4 can only support 4.29 billion of those addresses. The rest of this, we very commonly use network address translation or other methods to be able to communicate with all of these devices with such a limited number of addresses.
And as you may already be aware, there are no more IPv4 addresses to be assigned. We have hit the limit to the number of IP version 4 addresses that we’re able to use. We’ve been able to provide ongoing support for IP version 4 using network address translation, and the internet configuration that you use at home and at your office uses network address translation to be able to connect hundreds or even thousands of devices to the internet using a minimal number of IP version 4 addresses.
Although this works with most of the applications that we use, there are certain apps that would prefer not to use network address translation, and this simply creates more complexities and difficulties for those of us that need to communicate over these IPv4 networks. Fortunately, we have a solution to this limited number of addresses, and that solution is a new version of IP, referred to as IP version 6.
IP version 4 addresses are 32 bits in length. IP version 6 addresses have a 128-bit address, which gives us a much larger address space to use when we’re assigning these addresses to all of those many devices on the internet. Another way to visualize this would be to say that every grain of sand on earth could have 45 quintillion unique IP version 6 addresses. You can see that this larger address space with IP version 6 resolves that IP address constraint that we have with IP version 4.
There are a number of differences between an IP version 4 address and an IP version 6 address. This is an IP version 6 address, fe80::5d18:652:6ffd:8f52. You can see that is a very different style of addressing than IP version 4, where we were only dealing with decimal numbers and periods. In IP version 6, we are using hexadecimal values, and we’re separating those with a colon.
If we were to write out that entire address into its entire 128-bit form, you can see that it is completely listed here. And that is a much larger address than we deal with with IP version 4. If you wanted to view this in a binary form, you can see that we have the representation of that same address listed in binary.
You can see here that each section of an IP version 6 address that we separate with colons is 16 bits in length. You can see the 16 ones and zeros listed in each one of those sections. This also means that each section is two bytes in length, and you may also see it represented as two octets in length. So in total, the IP version 6 address is a total of 128 bits or 16 bytes in total.
You might see an IP version 6 address written out with all 128 bits being shown on the screen. But you might also see these addresses listed in a compressed form, which makes it much easier to be able to read.
When we’re using this compressed form of an IPv6 address, there are a number of rules to keep in mind. One of those rules, if there are groups of zeros that are together, we can abbreviate that entire group by simply replacing those zeros with a double colon. We can only do this one time in an address, but usually that’s all we need to make this address much easier to read.
We also can remove leading zeros from each group within the IP version 6 address. Let’s take an IPv6 address and perform this compression to see what that would look like.
The IPV 6 address will work with is 2600:DDDD:1111:0001:000. And you can see the zeros go all the way through to the end to the number one. Our first rule here is that we can remove any of these leading zeros that might be in all of these groups. This means that our IPv6 address with those zeros removed would be 2600:DDDD:1111. And then each of those leading zeros in all of the remaining groups would be removed.
You’ll also notice that there are three individual groups here that are simply zeros. And one way that we could simplify the writing of this IP address is to abbreviate two or more of those groups together with double colons. So all three of those zeros would be removed, and we would replace them with one series of double colons. This means that we would have a very simplified form of this address.
Instead of having all 128 bits of that address shown on the screen, the address is now simply written as 2600:DDDD:1111:1::1. Let’s look at another IPv6 address and perform the same compression.
This IPv6 address is 2601:04C3:4002:BE00:0000:0000:0000:0066. Our first step would be to remove the leading zeros in all of this. We have our second group has one zero in front of it, and there are a number of groups at the end that have leading zeros that we can simply get rid of. You’ll notice in this example that there are three different groups of zeros that are combined together, so we can remove all three of those zeros and replace it with a double colon. This greatly simplifies this much longer address into 2601:4C3:4002:BE00::66.
As you can see, the IP version 6 addresses are very different than the IPv4 addresses that we’re used to seeing. And because of this, IP version 6 and IP version 4 cannot directly communicate with each other. Therefore, we need some method to be able to have these older legacy systems that only understand IP version 4 be able to communicate on our more modern IP version 6 networks.
This creates some communication challenges when trying to combine IP version 4 and IP version 6. But fortunately, there are a number of different ways to bridge this gap. One of these methods would be to tunnel the traffic. We would either tunnel IP version 4 with an IP version 6 or tunnel IP version 6 with an IP version 4. This would give us a way to communicate even across networks that were very different than the protocol that we were using.
Another way to bridge this gap would be to use a dual stack configuration where the system that you’re using can communicate with both IP version 4 and IP version 6. And another way would be through the process of translation, where we are converting one IP version 4 address into a completely different IP version 6 address.
Obviously, these are stopgap measures, and they’re not designed to be a long-term solution for connecting these different types of networks together. Ideally, the best long-term solution would be for all of us to move to IP version 6. And hopefully, one day, we’ll be able to take all of our systems and be able to run them as a pure IPv6 environment.
In the early days of IPv6, where we did not have a lot of infrastructure devices that understood IPv6, we did a lot of tunneling of that IPv6 traffic. This was obviously designed to be a short-term use. And these days, it’s not very common to still see this tunneling being used.
One of these tunneling types is 6 to 4 addressing. This allows us to send IP version 6 traffic over an existing IP version 4 network. It creates an IPv6 address based on the IP version 4 address that you’re currently using, but it requires you to have a specialized relay router to be able to transfer that data. And one big disadvantage of 6 to 4 addressing is it does not support any type of network address translation. Because of both those limitations and because we have more devices these days that natively support IP version 6, we no longer commonly see 6 to 4 being used, and this functionality has now been removed from all Windows versions.
If you can tunnel IP version 6 traffic across an IPv4 network, you can also do the reverse with 4 in 6 tunneling where we can tunnel IP version 4 traffic across an existing IP version 6 network. Both of these were used as relatively short-term solutions, and it’s very unusual to find 6 to 4 addressing or 4 in 6 tunneling still being used on our enterprise networks.
A much more common method of migration and one you’re probably using on your existing system is dual-stack routing. This allows us to use both IP version 4 and IP version 6 at the same time on the same system. You might have an Ethernet adapter on your computer, and that Ethernet adapter has both an IP version 4 address assigned to it and an IP version 6 address assigned to it. The IP version 4 side works exactly the same as it always has, and all of your applications that use IP version 4 can use that address to be able to communicate onto the network. If you have applications that would prefer using IPv6, they can use the IPv6 addressing associated with that Ethernet adapter.
These applications will use the IPv6 address that is assigned to your Ethernet adapter. It will use the routing table within your system for IPv6, which is a different routing table than you’re using for IP version 4. And all of the IPv6 settings that are associated are all independent from anything that’s happening with IP version 4. This tends to be a very good middle ground because our application can choose IP version 4 or IP version 6, and either one of those will work properly on the network.
One of the things that we used with IPv4 to minimize the restriction that we had with IP addresses is to perform a network address translation. We would take our existing internal IPv4 address and translate that into an IPv4 address that can be routed across the internet. We can perform a similar translation to move between IPv4 and IPv6. This translation is called NAT 64, and it allows us to seamlessly translate IPv4 and IPv6.
Just as we need a specialized network address translation router when we’re using IPV 4, we also need a specialized router when we’re using NAT 64. This allows us to take a device that communicates via IPv6, but still allow it to communicate with devices that only communicate using IP version 4. The key is in the middle, we’re able to use a NAT 64 capable router to make that translation change between those two protocols. This also uses a specialized DNS server to be able to translate the DNS requests from IP version 4 to IP version 6. This is called DNS 64, and it’s an important part of the overall NAT 64 process.
For example, let’s say that you wanted to communicate from your device, which is an IPv6 client, and you wanted to communicate to professormesser.com. Let’s assume for this example that professormesser.com can only communicate using IPv4.
The first thing that happens, of course, is we need the IP address of professormesser.com. So we send a DNS request to our DNS 64 server. This server is going to make a DNS request on our behalf to that IPv4 network containing the DNS server that is used by professormesser.com.
And of course, that DNS server is going to respond back with the IP version 4 address associated with that server. Once that IPv4 address is received by the DNS 64 server, it creates an IP version 6 version of that address that redirects it to the NAT 64 router. To the IPv6 client, it thinks it’s received the IPv6 address of professormesser.com, but it’s really received the IPv6 address of the NAT 64 router.
So now when our browser needs to communicate to professormesser.com, it sends its initial SYN to that IPv6 address, which is the NAT 64 router. That router is responsible for performing the network address translation, where it is able to take the IPv6 address that we use and translate that into an IPv4 address that the web server understands. This process is obviously reversed when the response is sent back, allowing these two devices to communicate to each other, even though one device only understands IPv6, and the other device only understands IP version 4.