Posted by Recently I’ve been studying for a public tender that will be happening in my region, and one of the main topics is something that have been discussed in the computer networks for about 2 or 3 decades: The IPv4 and IPv6 addressing transition.
This post has been on draft for around a week now. Well, the public already passed and I’ve been really busy with work and studies, so the post was delayed again and again. But it’s time to finish it!
What’s the problem with the addressing?
The IPv4 addressing (created in 1980) is used to address every computer that connects to the internet in an individual identification number, with a pool of 2^32 possibles addresses, or 4.292.967.296 addresses. This might seem as a lot in the first sight, but believe me, it’s not: it needs to be divided in sub-pools to be distributed around the world, around companies and providers, and also there’s some addresses ranges that are reserved for specific uses in the algorithms that makes the networks work, so a lot of those are reserved for several other usages.
Once those addresses started to exhaust, some “work arounds” were created to try to give more time while a new solution was being developed. One of those solutions was the Network Address Translation (NAT) protocol. The idea is: we define an address range to be used behind one only valid address and make this translation when entering in a network.
With that in mind, a new standard called the IPv6 was created in 1998. This time, the address range would be of 2^128 addresses, that’s nearly enough to address every grain of sand in the planet, so I think we won’t have problems with address exhausting, right?
But yet, think that the whole internet was built upon a model, the TCP/IP model, where the addressing protocol we had was the IPv4 version. Now think that the internet is not made of software: most of the equipments that make the interconnection between the providers is hardware-based, so it can be perfomatic enough to deliver an economically-efficient throughput to the connections. Software can be easily upgraded, but hardware not: you need to usually substitute the whole equipment. So it turns this transiction into an economic problem: is it money worth spent for the economic return? I can’t simply substitute my equipments all at once, so how to do that in progressive, economic-returnable way?
That’s where some technologies enters in scene: the translation technologies.
A few ways of translating between IPv6 and IPv4
Imagine you have the following situation: Your company’s network addressing is based in IPv6, since customer-grade equipments are way more affordable and updatable than provider-grade equipments, but your provider and mostly of the internet still uses IPv4, and only IPv4, for communication. Their equipments can’t understand my packets with the IPv6 header, they’ll simply think that my header is corrupt and drop it. So how to make my packets get there?
One possible solution is: translate my IPv6 address to an equivalent IPv4 address, mark it up in a table and send it through IPv4. Once it gets back, I query my table to get relative IPv6 address and translate it back to IPv6 to my network. Seems simple, right? But here’s something you need to have in mind: keeping things in a table costs memory, and high-speed memory (since we don’t want our traffic bottlenecking while translating, correct?) is expensive and makes the product more expensive. So maybe there are some drawbacks to this idea.
Another scenario: your network is IPv6, the server you’re trying to reach is IPv6, but your provider only works with IPv4. What to do? Well, here’s an idea: the Headers of each layer 2-4 in a packet is chained one to another using the “next header“, “ethertype“, “protocol” or other similar fields to tell the equipment processing the packet what will be the next expected “format” to be read. What if we define a type that simply tells the equipment that “whatever’s over this IPv4 header is just Payload“? Then we could put any content there that won’t be processed until it reaches another equipment that says “well, this type means there’s something useful inside, let me just take this header of and process it as a new packet”. Then, we put the IPv6 header and the other following headers inside the IPv4 “payload”. This way we’re creating a Tunnel to travel the IPv6 content inside a IPv4 header that can be understood by our provider’s network.
These are two approaches for handling this “transition” phase we’re living from IPv4 to IPv6, until the whole internet can speak IPv6. The first one, translating the packets in a stateful approach, is used by techniques like NAT64/DNS64, 464XLAT and others, while the second approach is used by Teredo Tunneling, 6in4 and others. We can discuss in more details each one of those in another topic.
That’s all for now, folks!
This post took about a week to be finished, I simply didn’t have time or energy to stop and write. Hope the next days will be better and I’ll be able to write more here. Like it or not, it’s interesting for me to keep this Portfolio updated and with more interesting content. I’m trying to get the basics of every topic before getting into more specific content, but once it gets there, maybe it’ll get easier for me to write about (kinda paradoxical, right? the more basic topics are harder to write about hahaha).
Cya!