Top 10 IPV6 Facts that every Network Engineer MUST Know

, September 8th 2019

Over the past 10 years, global adoption of IPV6 has grown from less than 1% to now more than 25% of all Internet traffic. The relevance of IPV6 to a network engineer's career is now higher than ever before. As such, enjoy today's post on our top 10 IPV6 facts that every Network Engineer must know.


Check out this great graph by Google on IPV6 adoption; adoption is rapidly on the rise. At the same time, however, a disproportionate amount of network engineers haven't exposed themselves to the technology yet.

For those who want to stand out, having a solid IPV6 skillset is certainly an option.


The primary motivation for the creation of IPV6 was the need for a larger address space.

An IPV4 address contains 32-bits of data which provides a maximum address space of 232 addresses - a little more than 4 billion addresses.

An IPV6 address, on the other hand, contains 128-bits of data which provides a whopping 2128 addresses. This is far greater than the number of stars in the universe. We can all confidently agree that we won't be running out anytime soon.

3. NAT in IPV6

The NAT protocol, Network Address Translation, was created to minimize wasted IPV4 addresses by aggregating many private IPV4 addresses to a single public address.

With IPV6, however, there is no danger of running out of addresses so NAT is no longer standard practice. It is still possible to configure in theory but isn't recommended - some people suggest that NAT offers security benefits but the reality is this wasn't what the protocol was created for and there are much better ways to secure a network than through NAT.

4. DHCPv6 and SLAAC

The IPV4 variant of DHCP will disappear in IPV6. Two options will take its place - it is yet to be determined which will gain dominant popularity.

  1. SLAAC - Stateless Address Autoconfiguration - In SLAAC, a host configures its IPV6 address by listening to Router Advertisement (RA) messages. The host will use the RA in junction with other data to allocate itself a unique address. The protocol is stateless as no device on the network tracks the list of configured addresses.
  2. DHCPv6 - This protocol is somewhat similar to the stateful IPV4 version of DHCP. Interestingly, SLAAC can also use DHCPv6 to obtain data for use in the self-allocation of a stateless address. So the DHCPv6 protocol may be used in both a stateful or stateless setup depending on the desired design.


The standard way to write an IPV4 address is to split the value into 4 octets and write each octet in decimal notation.

This method would not be concise enough for IPV6. As such, IPV6 uses hexadecimal notation with each "hextet" separated by a colon. A hextet is 16 bits wide which is double the size of an octet. An example of an IPV6 address is given below.



RFC 5952 recommends a shorthand format for writing IPV6 addresses. This makes addresses much more readable for humans. The notation rules are simple.

  • Leading zeros within each hextet are omitted.
  • Double colons are used to completely omit succeeding hextets with values of zero.

For example, we can write our earlier IPV6 address using the shorthand form below.



The most common loopback address in IPV4 is

For IPV6, the most common loopback address is shown below.


We can use our shorthand notation to write this address ultra concisely as shown below. It's even more concise than an IPV4 address!



In IPV4, the network portion of an address will vary in size. A subnet mask will describe the number of bits in an IP address that represent the network portion.

In IPV6, the network portion of an address is almost always 64 bits. This portion can be further broken down into two parts. The first 48 bits represent a global unicast address. The next 16 bits represent a subnet ID.


Anyone who has managed an IPV4 DNS server will be well acquainted with "A" records used for hostname resolution.

In the IPV6 world, DNS is still relevant but uses "AAAA" records instead of "A" records. These records are also known as Quad A records.


IPV6 is not inherently compatible with IPV4.

As such, technologies have been developed to create compatibility for the long migration period as the world moves to IPV6. Two such technologies are "Lightweight 4over6" and "NAT64".


Hopefully these IPV6 facts have helped your understanding of the fundamentals if you didn't know them already!

Finally, if you haven't heard of Ultra Config Generator, I would highly recommend you check it out. We designed the product to allow network engineers to generate and automate network configuration in a highly flexible, efficient and elegant manner. Our users love the application and I hope that you will too.

Take care until next time!

Ultra Config


Subscribe to the Blog

Subscribe now and never miss a new post!