IPv6: Starter to Master

Last updated: 19/06/2024

Reading Time: 23 minutes

When starting my learning journey to IPv6, I underestimated the learning curve’s steepness. I thought I could watch a quick YouTube video, add a few more bits to my IPv4 address, and I would be good to go – how wrong I was. I think the majority of the problem is although IPv6 has been around for some time, the content is still limited, focusing on one particular concept and not bringing it all together. Every blog/video I read/watched would introduce a new terminology or concept, and I would spiral into the depths of the Internet learning one concept after another struggling to piece it all together.

In this blog, I will provide a single page with the most important things you need to know about IPv6, how all the components piece together and the fundamental differences between IPv4 and IPv6 to demonstrate the benefits.

The first thing to note is IPv6 is more than just IPv4 + more addresses. IPv6 has been built pretty much from the ground up. To name some of the key changes:

• New Header format – The IPv6 Header has been massively simplified when compared to an IPv4 Header and packet forwarding made more efficient (by removing redundant fields such as checksums as we already have these at Layer 2 and Layer 4, so no need at Layer 3). It is also fixed length vs. the variable length in IPv4 headers which in theory should simplify packet processing.
• Host Addressing – There is no need for the Dynamic Host Configuration Protocol (DHCP) to provide a Host with an IP as it can generate one itself. (Slightly strange concept I know, more on this later).
• Efficient LAN Interaction – Replacing Address Resolution Protocol (ARP) with Neighbour Discovery Protocol (NDP) and the removal of Broadcast Addresses.
• Extensibility – Extention Headers after the IPv6 Header provide additional functionality. These extensions are not processed by Intermediate Routers, thus no performance impact.
• Security – IPv6 Header Extensions allow easier implementation of IPSEC. It’s not mandatory and doesn’t mean all IPv6 packets are encrypted, but a useful feature.
• Fragmentation – IPv6 packets are not fragmented by intermediate routers if they exceed the permitted Maximum Transmission Unit (MTU) and an ICMPv6 “Packet Too Big” Message is sent to the sender. This is not to say fragmentation is not supported, but only performed by the source and destination hosts, and not the routers themselves.

IPv6 Address Structure

We’re running out (have run out?) of IPv4 space as it only gives us 2^32 addresses (around 4.3 billion) which the founders of the Internet thought was enough, but clearly not given the Internet was never designed for what we use it for today. IPv6 was created to replace IPv4, giving us 2^128 addresses (340 trillion trillion trillion) addresses, which we should theoretically never run out of. To try and keep addresses as short and friendly as possible, Hex notation is used to represent IPv6 Addresses, and rules are applied to reduce its length (but not change its value) to make it easier on the eye.

IPv6 is split into 8 Hextets (8 x 16 bits), separated by a colon (:) versus IPv4 which is split into 4 Octets (4 x 8 bits), separated by a dot. An example of an IPv6 address would be 2001:0000:130F:0000:0000:09C0:006A:130B/128. It’s not very pretty, however, IPv6 Compression rules allow us to make the address more human-friendly.

Let’s take the original IPv6 address – 2001:0000:130F:0000:0000:09C0:006A:130B/128.

Rule 1: The leading 0s in each group can be removed as 0000 is the same as 0. I.e. 09C0 is the same as 9C0. 006A is the same as 6A. If you’re still not sure why, think of it this way. In the real world £00537 = £537, and we simplify it but removing leading zeros, but the value itself does NOT change. However, if you had £5370, this does NOT equal £537 by removing the zero, which is why the standard states leading 0s, not all 0s, otherwise this changes the value completely i.e. a different address than what was intended.

After applying Rule 1, this gives us – 2001:0:130F:0:0:9C0:6A:130B/128.

Rules 2: If an IPv6 address contains two or more consecutive groups of zeros, they can be replaced by a double colon (::).

After applying Rule 2, this gives us – 2001:0:130F::9C0:6A:130B/128.

We know there should be 8 Hextets, and in the above example there are 6 Hextets, therefore the :: represents 2 groups of Hextets i.e. 0000:0000. Note, you can only do this ONCE in your address, so if you have 4 groups of Hextets containing all 0s such as 0000:0000:0000F:0000:0000, you can only use the :: notation ONCE, so this would be either ::F:0:0 or 0:0:F:: (both are valid). If we were able to use this notation multiple times, we wouldn’t be able to determine if the split is 1:3, 2:2 or 3:1 on either side of the F Hextet, and fundamentally this would change the address. While both ::F:0:0 and 0:0:F:: are valid, the best practice is to use the :: notation for the leftmost groups of 0s, therefore ::F:0:0. In addition to this, RFC5952 states that the longest group of concurrent zeroes must be shortened.

IPv6 Address Types

There are various IPv6 address types, and in this section, I will mention the key ones that you need to know. Throughout this blog, I will use all of the prefixes mentioned to demonstrate real-world uses:

Important things to mention:

1. IPv6 Unique Local Addresses (ULAs) and IPv4 Private/RFC1918 CIDRs have a similar concept, but this does NOT mean that you should use Unique Local Addresses (ULAs) for Private Networks. Leave the thinking of Public/Private IPs and the use of NAT’ing as a security measure in IPv4 land.
2. IPv6 Hosts have multiple IPv6 Addresses of the same or different type, used for different functions or services. This may include multiple Global Unicast Addresses (GUAs).
3. IPv6 Link-Local Addresses and IPv4 Link-Local Addresses have slightly different uses. In IPv4, 169.x address is allocated to Hosts when DHCP fails to supply an IPv4 Address. In IPv6, Link-Local Addresses are used next to other IPv6 Addresses and are typically used for Neighbour Discovery (Hosts and Routers).
4. The Broadcast Address/Address Type in IPv4 does not exist within the IPv6 Address Type. A similar function is embedded within the IPv6 Multicast Type with some improvements. This also means that Address Resolution Protocol (ARP) is not used in IPv6 given this relies on Broadcasting.
5. IPv6 supports any cast addressing, similar to IPv4.

Carving the IPv6 Space

When designing IPv4 Networks, Network Architects are very conscious of how the Network is segmented given the limited address space and would economically assign subnets. With IPv6, this is no longer a concern given the large number of addresses, and the IETF have a standard (RFC3819) which defines how the IPv6 space should be segmented.

RFC3819 states:

• Operators should assign a /48 prefix to each business customer.
• Operators should assign a /56 prefix to each residential customer.
• The minimum size of a ‘network’ should be /64. Allocating a subnet smaller than this will break functionality, specifically IPv6 Protocols such as SLAAC. More on this in a bit.

If a /64 is allocated, this cannot be carved into smaller subnets given it will break IPv6 functionality, and therefore only operate as a flat network, thus even residential customers should be allocated a /56 prefix to allow subnetting.

IPv6 is Aggregatable, in fact, there’s a whole RFC standard on Aggregatable Global Unicast Address Format (RFC2374). The standard recommends the following IPv6 Allocation Architecture:

Source: RFC 2374 – An IPv6 Aggregatable Global Unicast Address Format (ietf.org)

The Format Prefix (FP) is already defined and set by the IANA (currently 2003::/3) and the Top-Level Aggregation Identifier (TLA ID) denotes the Regional Internet Registries (each RIR has many). The combination of the FP, TLA ID and the Reserved Prefix (RES) is allocated to large Internet Service Providers (ISPs) i.e. a /24, though this does vary drastically. ISPs can then allocate Next-Level Aggregation Identifiers (NLA IDs) to each business customer which gives us a /48, leaving Network Architects to carve the /48 by Site, Region, Environment etc. that can be easily identified by the Site-Level Aggregation Identifier (SLA ID).

This standardised aggregatable structure and continuous IPv6 blocks are essential in ensuring that we do not complicate our internal network routing and structure by being able to summarise routes, and most importantly it allows us to ensure the Default-Free Route Tables (Global/Internet Route Tables) in Top-Level Routers on the Internet are kept within reasonable margins, given the large address space. If we were not able to efficiently summarise routes on the Top-Level Routers that could have an impact on the Internet Backbone as a whole.

IP Address Allocation to Hosts

Immediately, when you read Host IP Allocation you probably assume DHCP. How else would a host get an IPv6 address without statically setting it? Magically generate one myself? Actually, the answer is yes. In addition to this, it is not one IP allocation to a Host – a Host will have lots of IPv6 addresses. Leave the thinking of 1 IP : 1 Host in IPv4 land, as we are no longer bound by limited address spaces.

While DHCPv6 does exist, it didn’t exist in the original plans for IPv6 and as of 2024, DHCPv6 is not fully supported across devices.

Generating a Link-Local Address (LLA)

The Link-Local Address of Host is generated using EUI-64 (Extended Unique Identifier) Address Format. It takes the MAC Address of the device (48-bits) and splits it into 2 x 24-bits; the first 24-bits represent the Organisationally Unique Identifier (OUI i.e. the manufacturer) and the second 24-bits represent the Network Interface Controller (NIC). It then inserts FFFE between the two blocks and joins them back together, giving a 64-bit Interface ID. The first 8-bits are then converted to binary, and the 7th bit is flipped and then converted back to Hex. The dashes are converted to colons to form a correctly structured IPv6 address. This 64-bit Interface ID is appended to the FE80::/64 Link-Local Prefix giving a 128-bit IPv6 Link-Local Address that is accessible only within its network segment given its non-routable. It is compulsory to have a Link-Local Address and serves many functions, unlike IPv4 169.x Link-Local Addresses.

Duplicate Address Detection (DAD) is performed to ensure there is no clash in the network segment for the generated Link-Local Address, even though this is very unlikely (unless there is MAC Spoofing on the network, but that’s a whole different topic). We will cover exactly how Duplicate Address Detection (DAD) works in a later section, but for now you can assume the address is unique.

Generating a Global Unicast Address (GUA)

We need a Global Unicast Address (GUA) as a Link-Local Address (LLA) is not routable and only allows us to communicate within our Local Area Network (LAN) segment (such as communicating with our router, but the router will not forward on the packet). The mechanism used to generate a Global-Unicast Address (GUA) IPv6 Host Address is SLAAC; Stateless Address Auto Configuration (defined in RFC4862). SLAAC does not configure the DNS Server information, which is the main reason people don’t really like to use it.

Now that the Host has a Link-Local Address (LLA), it can start the process of auto-configuring a Global-Unicast Address (GUA) to access the Internet. First, the Host sends a Router Solicitation (RS) ICMPv6 Message from its Link-Local Address (LLA) to the FF02::02 Multicast Group that contains all of the Routers within the Network (I will cover IPv6 Multicasting later, but for now you just need to know that all the routers are within this well-known group). The Router will respond back with a Router Advertisement (RA) ICMPv6 Message which will contain the Global IPv6 Prefix assigned to the Network. The Host combines the Global IPv6 Prefix with the EUI-64 Interface Identifier giving us a unique Global-Unicast Address (GUA). The Host will set its default gateway to the Link-Local Address of the Router which the Router Advertisement (RA) Message came from.

Backtracking a little, remember that an IPv6 address is 128-bits and that you should never allocate less than a /64 prefix to a subnet as it could break functionality, this is the reason. If you allocate a subnet smaller than /64, EUI-64 can’t do its thing.

Why does this work? Think of it this way, my Internet Service Provider (ISP) has allocated me a prefix which I know is globally unique. Within my network, I have already confirmed that the Interface ID component (generated using EUI-64 based on my MAC Address) of my Link-Local Address is unique, thus the combination of my IPv6 Prefix + Interface ID must also be unique. However, Duplication Address Detection (DAD) is still run on the Global-Unit Address (GUA) to double-check that the Host IPv6 Global Unicast Addresses (GUA) is unique.

Domain Name System (DNS) for Hosts with SLAAC Acquired IPs

As part of the Router Advertisement Message to Hosts when acquiring Global-Unicast Addresses (GUAs), it is not just the Global Prefix they receive. There is a whole host of information the Router provides, and one of the key pieces of information is if a DHCPv6 Server is available. We refer to this as Stateless DHCPv6, which is used in combination with SLAAC. The O-Flag (Other Information Flag) within the Router Advertisement (RA) Message is set to 1 (true) indicating DNS Server information is available, therefore the Host sends a DHCPv6 SOLICIT message destined to the all-DHCPv6 Multicast Address Group (FF02::1:2) to which the DHCPv6 Server replies back with a DHCPv6 ADVERTISE indicating that the service is available.

The Host then sends a DHCPv6 INFORMATION-REQUEST message asking for more information, which the DHCPv6 responds back with a DHCPv6 REPLY message that contains the DNS server list and a domain name.

If you’re thinking that this is a lot of faff and back and forth communication – I agree, and DHCPv6 Rapid-Commit can help reducing 4 messages to 2. The Host would need to use the rapid-commit option indicating it wants to speed up the exchange, which would ensure the DHCPv6 Server responds back with DHCPv6 REPLY providing the information. Rapid-Commit does need to be enabled on the DHCPv6 Server.

Stateful DHCPv6

With Stateful DHCPv6, the Router takes care of assigning the Global Unicast Address (GUA), Default Gateway and the DNS Server Information, functioning pretty similar to how DHCP works in IPv4. It works like so:

1. Host sends out a Router Solicitation (RS) message to the all-routers Multicast Address Group; FF02::02.
2. Router replies back with a Router Advertisement (RA) Message with the M-Flag (Managed Address Configuration Flag) set to 1 (true) and the A-Flag (Autonomous Address Flag) set to 0 (false). This indicates that SLAAC is not permitted and it must use Stateful DHCPv6. The Router Advertisement (RA) is sent to FF02::1 (all nodes Multicast Group), not just the Host sending the Router Solicitation message.
3. The Host sets the default gateway with the Link-Local Address of the Router.
4. The Host starts the 4 message exchange with the DHCPv6 (which we previously discussed in Stateless DHCPv6) to retrieve the DNS information, but also the Global-Unicast Address (GUA).
5. The Host performs Duplicate Address Detection (DAD) on the Global-Unicast Address (GUA) it was allocated to ensure it is unique.

One thing to mention, setting the A-flag is not mandatory however if it is set to true, two Global-Unicast Addresses are allocated, one DHCPv6 provided and the other SLAAC generated. Generally, organisations want to track the IPs on its network therefore this should be set to false.

Router Flags

Expanding on Router Flags, here is the matrix of the combination of flags and their outcome to ensure you understand the actions of these.

IPv6 Neighbour Discovery Protocol, Duplicate Address Detection & Multicast Addressing

It’s hard to explain these concepts separately as they are very interlinked, so it’s much easier if I explain them all together.

There is quite a bit of a difference in how neighbour discovery works between IPv4 and IPv6. In IPv4, when Host A wants to talk to Host B, it will check its Address Resolution Protocol (ARP) Cache to find Host B’s MAC Address. If it’s not there, Host A will send an Address Resolution Protocol (ARP) Request to the Broadcast Address which ALL devices on the Local Area Network (LAN) will receive asking Host B to reply back with its MAC address. In IPv4, this may be okay given the relatively small address space, but now with IPv6 where networks will be fundamentally huge, this method is not efficient and would generate large amounts of traffic and noise on the network, and there actually is no longer a Broadcast Address within IPv6.

Instead, Neighbour Discovery (ND) is done using the Neighbour Discovery Protocol (NDP) which uses Multicast Messages, instead of Broadcast Messages. The ND Protocol is powered using the ICMPv6 protocol and has many types supporting both Neighbour/Router Solicitation and Advertisement, which I’ve touched upon lightly in previous sections.

One thing to note, ICMPv4 has a ‘bad’ reputation and is often blocked by network or security devices as it’s seen as a security risk (by devices echoing back). ICMPv6 is an integral part of IPv6, to the point where IPv6 will not function properly without ICMPv6.

As a reminder, the Multicast Address Prefix in IPv6 is FF00::/8. There a couple of important IPv6 Addresses/Multicast Groups to be aware of within this Prefix (some of which I’ve briefly touched on already):

• FF01::1 – All Interfaces on the same Host
• FF02::1 – All Nodes within a Network Segment
• FF02::2 – All Routers within a Network Segment
• FF02::101 – Network Time Protocol (NTP)
• FF02::1:2 – All DHCPv6 Agents

When a Host joins the Local Area Network (LAN), it will add itself to the Well-Known Multicast Groups, and also generate its own ones for each IPv6 Address that’s allocated.

How does Duplication Address Detection (DAD) work?

I’ve mentioned Duplicate Address Detection (DAD) quite a few times, but how exactly does it perform this functionality? Each IPv6 Host will be part of the FF01::1 and FF02::1 Multicast Groups. Each IPv6 Host will also get a Link-Local Address (LLA) and a Solicited-Node Multicast Address which is a combination of the FF02::1:FF Prefix + the last 6 bits of its Link-Local Address (LLA).

For example, if a Hosts Link-Local Address (LLA) is FE80::1111:2222:3333:4444, the last 6-bytes (24-bits) are taken (334444) and appended to the FF02::1:FF Multicast Prefix. Therefore the Hosts Solicited-Node Multicast Address IP/Group is FF02::1:FF33:4444.

So, we can deduce that if two Hosts have the same Link-Local Address (LLA), they will also be listening for messages on the same Solicited-Node Multicast Group. To perform Duplicate Address Detection (DAD), the Host will send an ICMPv6 Type 135 Message with the IPv6 Header destination address set to this group and the source address set to the IPv6 Unspecified address (remember, this is the ::/128 address). The ICMPv6 Payload will have the Target set to the Link-Local Address (LLA). All nodes within the Multicast group will receive the packet and check the ICMPv6 portion and if the Target matches any of its own addresses, it will reply back that this IPv6 address is in use. If there’s no reply, the host will conclude the address is unique. This technique is known as Neighbour Solicitation (NS) and happens in less than a second. If a Host has the same IPv6 Address, it will respond back with a Neighbour Advertisement (NA) Message, which means there is an IPv6 Address conflict.

In this section I’ve mentioned Link-Local Address (LLA) as an example, but this process is used for ALL Unicast IPv6 Allocations, meaning Global Unicast Addresses (GUAs) also go through this process.

How do two Neighbours communicate on the same LAN?

This will be much easier to explain with an example.

• Host A’s Link-Local Address (LLA) is FE80::1111:2222:3333:4444.
• Host A takes the FF02::1:FF Well-Known Prefix and appends the last 6 bits of its Link-Local Address (LLA). Host A’s Solicited-Node Multicast Address is FF02::1:FF33:4444.
• Host A tries to communicate with Host B, but doesn’t have its MAC Address.
• Host A knows Host B’s Link-Local Address (LLA), therefore NDP automatically forms the Solicited-Node Multicast Address Group and sends an ICMPv6 Type 135 Neighbour Solicitation (NS) Request along with its own MAC Address.
• As Host B is the only member of that Multicast Group, only it got the NS Request. Host B sends a ICMPv6 Type 136 Neighbour Advertisement (NA) Message back, along with its MAC Address back to Host A.
• Host A and Host B have each other’s MAC Addresses and are able to communicate.

This is super powerful because it means that as long as I know my destination IP, I can generate my destinations Solicited-Node Multicast Address to retrieve the MAC Address to start communication, and it is retrieved using a much more efficient and secure way compared to IPv4.

How do I discover the Routers on my LAN?

I briefly touched upon this when describing how Global Unicast Addresses (GUAs) are allocated, as we need to retrieve our Network Prefix from the Router and Stateful DHCPv6. Similar to how Neighbours establish communication with ICMPv6 Type 135 Neighbour Solicitation (NS) and ICMPv6 Type 136 Neighbour Advertisement (NA), Routers have a similar concept. Routers use ICMPv6 Type 133 Router Solicitation (RS) and ICMPv6 Type 134 Router Advertisement (RA) to make their presence known.

Routers make their presence known often (normally every few minutes) by sending a Router Advertisement to the FF01::1 Multicast Group which contains all of the Hosts. In addition to this, when a Router receives a Router Solicitation (RS) from a Host, it will not only send a Router Advertisement (RA) back to the the Host that requested it, but it will send it to the FF01::1 Multicast Group, therefore all Hosts will receive it.

The Router Advertisement (RA) contains a lot more information than Neighbour Advertisements. It includes fields such as the Global Prefix (used when generating GUAs), whether to use DHCPv6 or SLAAC for GUA IP Allocation via the Autonomous (A) Flags etc.

How will a Host know where to send the Router Solicitation if it doesn’t know the Router IP? Simple, it will send the Router Solicitation (RS) Request to the FF02::2 Multicast Group which contains all the Routers.

_________________________________________

Quick check-in so far (Optional)

We’ve covered quite a bit so far, so I want to jot a few key points/summaries to make sure you have the concepts locked in. If everything is crystal clear, move on to the next section.

1. IPv6 Addresses are 128-bits denoted as 8 Hextets split with colons (:). There are compression rules which simplify the address without changing its value.
2. IPv6 Headers and IPv4 Headers are fundamentally different. Many redundant fields have been removed such as Checksums (which are handled at Layer 2 and 4 already).
3. IPv4 Broadcast functionality using Address Resolution Protocol (ARP) has been replaced with a more efficient IPv6 Multicasting function using Neighbour Discovery Protocol (NSP) powered using ICMPv6.
4. Hosts may have multiple IPv6 addresses, which may include multiple of the same type.
5. IPv6 Unique-Local Addresses (ULAs) are the equivalent of IPv4 RFC1918 Routes. This does NOT mean ULAs should be used within a Private Network.
6. There are standards on how IPv6 should be carved to ensure the address space is aggregatable, to ensure Global/Internet Route Tables are kept within its limits and no performance impact to Top-Level Routers given the large address space.
7. You shouldn’t allocate less than a /64 to a given subnet as it may break IPv6 functionality.
8. Hosts can generate their own Global-Unicast Address (GUA) which is the equivalent of IPv4 Public Addresses, using a process called SLAAC. This process does not provide DNS Server Information, but optionally you can use Stateless DHCPv6 for this.
9. Hosts can be allocated a Global-Unicast Address (GUA) using Stateful DHCPv6, which is the equivalent of DHCP in IPv4. They will receive DNS Server Information using this method, though not all Operating Systems support DHCPv6.
10. Duplicate Address Detection (DAD) is used to detect duplicate IP Addresses. This is used for any Unicast IPv6 Allocation such as Global-Unicast Addresses (GUAs) and Link-Local Addresses (LLA).
11. There are Well-Known Multicast Groups which allow a Hosts and Routers to detect other Hosts and Routers using Multicast Messages. They can also be used to detect DHCPv6 Servers on the Network.

_________________________________________

IPv6 to IPv4 Connectivity

You may be aware that IPv6 is not backwards compatible so you can almost think of there being two separate Internets; an IPv4 Internet and an IPv6 Internet. So in a IPv6-only environment, how you connect to IPv4-only instances?

There are a number of different techniques to facilitate the connectivity while we transition between IPv4 and IPv6 such as Tunnelling Techniques (such as Teredo, 6to4, 6in4 etc.) which works by encapsulating IPv6 datagram packets within IPv4 User Datagram Protocol (UDP) packets, mechanisms such as Translation Techniques which provide interoperability between an IPv4 device and an IPv6 device by changing the header of a packet, Protocol Translation and more.

One of the most common technique is (Stateful) NAT64 + DNS64 (RFC6052, RFC6146 and RFC6147), two separate technologies that work together. This works by embedding a 32-bit IPv4 Address into a 128-bit IPv6 Address. You may be thinking that this could potentially cause IPv6 conflict if you embed an IPv4 address into an IPv6 address, if the IPv6 is already allocated. However, NAT64 embeds the IPv4 Address into a Well-Known IPv6 Prefix that’s dedicated to NAT64; 64:ff9b::/96. Having this Well Known Prefix allows us to route IPv4 destined traffic to a NAT64 appliance, while IPv6 destined traffic can head straight out. NAT64 is known as a Provider-Side Translator (PLAT).

So we don’t have to embed the IPv4 address ourselves, DNS64 comes into play to form the IPv6 Address. Let’s look at an example:

1. An IPv6-only host wants to connect to ipv4-only.example.com.
2. The Host will do a DNS lookup to find an AAAA record (this is the IPv6 equivalent of an A record) but it does not exist. DNS64 will then check to see if an A Record exists.
3. If an A Record Exists, DNS64 will synthesise the AAAA Record from the A Record, where the first 96-bits will contain the Well-Known Prefix; 64:ff9b::/96 and the last 32-bits will be the Hex equivalent of the IPv4 Address, which is returned to the host.
4. Per the Hosts routing, traffic destined for 64:ff9b::/96 will go via a NAT64 appliance, while ::/0 will go our straight to the Internet.

Here is a graphical example:

Image source: https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/networking/nat64/ipv6-initiated-communication#idc9d9c2e1-8563-461f-b626-9662ef2c17d8

There are considerations with NAT64 + DNS64:

• It only works for cases where DNS is used to find the remote host address, if IPv4 literals are used the DNS64 server will never be involved. I want to emphasise this consideration as a handful of popular applications and protocols use IPv4 literals and as such will not work. Technologies such as Web Sockets, SIP, SDP, FTP, Skype etc. do not function with NAT64.
• Because the DNS64 server needs to return records not specified by the domain owner, DNSSEC validation against the root will fail in cases where the DNS server doing the translation is not the domain owner’s server.

An extension of NAT64 is 464XLAT (RFC6877) which is becoming popular especially in the mobile network space. It aims to overcome the limitations of Stateful NAT64 (Provider-Side Translation, PLAT) by also adding Stateless NAT46 (Customer-Side Translation, CLAT). As the name suggests there is an additional translation on the Customer Side before it reaches the Provider Side; where the device will translate the IPv4 Literal Address to an IPv6 Address, traverse an IPv6-Only Network, then the Provider will translate it from an IPv6 Address to an IPv4 Address, hence the name 4-6-4, and XLAT where the X represents both C (Customer-Side Translation) and P (Provider-Side Translation). This is a little more difficult to implement within the Enterprise space due to some Operating Systems not supporting C-LAT, and therefore 464XLAT (yet).

This is quite a confusing mechanism so I will explain with an example to make it clearer:

1. Assume a Host has only an IPv6 Address and tries to communicate to an IPv4 Literal Address, e.g. 1.1.1.1. In the world of IPv6, this is not a real address so its not routable, and DNS64 doesn’t embed the IPv4 Address into the IPv6 64::ff9b/96 Well-Known Prefix because DNS isn’t involved – it’s a literal address, therefore it’s never sent to the NAT64 (Provider-Side Translation) Device.
2. Customer-Side Translation (CLAT) is a daemon that runs on the Client device that acts as a NAT46, where the IPv4 Packets are translated to IPv6 Packets.
3. Now, doesn’t NAT46 require an IPv4 Source Address? And this is a IPv6-only Network? Correct. The IPv4 Address is ‘fake’ (a virtual IPv4 Address) that the Host Operating System assigns itself and tunnels traffic on this IPv4 Address over the Network’s IPv6 interface.
4. The IPv4 IP Address is embedded into the 64::ff9b/96 Well-Known Prefix by the CLAT process.
5. Traffic is then routed to a NAT64 Device (without the use of DNS64 given its an IPv4 literal) which is NAT’ed to a Public IPv4 Address to then access the IPv4-only Application.

IPv4 and IPv6 Preference on Dual-Stack Hosts

With the massive push to go to IPv6, you probably assume that if a Host is dual-stacked (has both IPv4 and IPv6 Interfaces), then IPv6 will always be preferred. Not exactly.

Per RFC6724, the current default policy table leads to the preference for IPv6 Global-Unicast Addresses over IPv4 Addresses, which is widely considered to be preferential behaviour to support greater use of IPv6 in dual-stack environments, however, the default policy table also puts IPv6 Unique-Local Address (ULAs) below all IPv4 addresses, including RFC1918 addresses. Meaning that if you have a Unique-Local Address and you have an IPv4 RFC1918 Address such as 10.1.2.3 assigned to a Host, 10.1.2.3 will be preferred over the Unique Local Address (ULA).

In my opinion, this is counter-intuitive and from the research that I’ve done, I cannot quite work out why this design decision was made. Even though I believe ULAs should generally not be used (few edge cases), they should have a higher preference than all IPv4 to facilitate the use of IPv6 over IPv4.

With this in mind, this makes the use of ULAs even less attractive, therefore should be avoided where possible.

Final Thoughts

IPv4 isn’t going away anytime soon, but IPv6 is here for good and sooner or later we will need to migrate or at least run dual-stack.

Cellular Network Providers are miles ahead with many now on IPv6-Only Networks, followed by Internet Service Providers but Enterprise Customers are still not there yet, but with the way the industry is heading – we will need IPv6 sooner rather than later. There are more and more cases where customers are leveraging native cloud services which consume large amounts of IP spaces, particularly container based workloads which would be a great candidate to use IPv6.

Running costs is also another driver that I believe sooner or later will drive Enterprise Customers to IPv6. IPv6 Addresses are a lot cheaper than IPv4, and we no longer need expensive NAT-capable devices in IPv6, though we will need it if we’re running a dual-stack environment. Implementation costs however may be expensive as you will need to evaluate the networking requirement’s of every single application to ensure it doesn’t break and is capable of running IPv6, and modify every single networking device – which is probably why a lot of customers haven’t adopted it. It requires a lot of effort in a brown-field environment.

I hope you learnt a thing or three :).