The Internet has a problem, with an ever-increasing amount of devices persistently connected, we are running out of addresses to provide through the originally developed and widely used Internet Protocol v4 (IPv4).

This has been anticipated since the late 1980s and all of the top-level address spaces have been allocated as of 2011. Do not fret, as there is an increasingly popular standard on the horizon, the Internet Protocol v6 (IPv6), which will vastly expand the number of addresses available. In addition, IPv6 provides some fundamental improvements to the outdated IPv4 architecture, helping to improve the performance and reliability of the routing of data to our precious connected devices.

The king is dead, long live the new digital messiah!

Addressing Architecture

One of the limiting factors of IPv4 is the number of unique addresses that may be allocated to connected devices. IPv4 has a 32-bit address space, allowing the enumeration of around 4.4 billion addresses to be allocated globally.

There are restricted blocks of addresses, used for special purposes such as for private networks, further dwindling the number of addresses that may be used for devices connected to the internet.

In contrast, IPv6 uses a 128-bit address space, allowing for a staggering 340 undecillion (trillion trillion trillion) unique addresses. It is hard to conceptualize the vastness of this span of numbers, but this quote from an article by CNN may help put it into perspective:

With IPv6, there are now enough IP combinations for everyone in the world to have a billion billion IP addresses for every second of their life.

Packet Headers

With a quadruple increase in address size, one might think that IPv6 packet headers, which specify the addresses the data is to be transmitted to and from, may be at least four times as large. In fact, the header size is only twice as large as seen with IPv4 packets.

This is due to changes to the structure of IPv6 packets by removing no longer needed components found in IPv4. These changes have made for more performant packet forwarding by creating as lean of a packet size as possible while supporting the necessary growth of the Internet. Meta reported seeing 10-15% faster page loads due to their transition to IPv6-only deployments in 2015.

Checksum Field Has Been Dropped

The IPv4 checksum field, which was used to verify that the datagram contained within a packet had not been corrupted during transit, has been dropped.

The reasoning behind this change is that devices already perform this action by validating the integrity of the transmitted data at the data link layer (Layer 2). Layer 4 protocols, such as TCP and UDP, are also encouraged to perform redundancy checks. This is done as a part of the default TCP operation. For UDP, checksum validation is optional in IPv4, yet is required to be used under IPv6.

Packet Fragmentation Has Been Dropped

IPv4 handles cases where the Maximum Transmission Unit (MTU), defining the maximum size of a packet, is smaller than the transmitted packet size, by fragmenting a packet along its destination into smaller units. IPv6 does not support fragmentation past the originating source. Routers will discard packets larger than the MTU defined on the interface. Instead, the source of the packet is responsible for fragmenting it using the appropriate size.

Address Types

Address type         Binary prefix        IPv6 notation
------------         -------------        -------------
Unspecified          00...0  (128 bits)   ::/128
Loopback             00...1  (128 bits)   ::1/128
Multicast            11111111             FF00::/8
Link-Local Unicast   1111111010           FE80::/10
Global Unicast       (everything else)

An IPv6 address is represented as eight groups of four hexadecimal digits, separated by colons. This can be shortened by using a double colon, ::, to represent consecutive zeros.

There are several important types of addresses defined by the IPv6 addressing architecture standards that we will learn about below.

Unicast Addresses

A unicast address is an identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address.

Link-local unicast addresses are special uniquely generated addresses defined and used locally to a particular network segment. Every interface supporting IPv6 is required to have a link-local address. These addresses are not guaranteed to be unique and are not meant to be routed across network boundaries.

Global unicast addresses (GUA) are globally unique and externally routable addresses on the IPv6 Internet. As defined by RFC4291, GUAs may be any address excluding the range of FF00::/8. The Internet Assigned Numbers Authority (IANA) has allocated the space 2000::/3 for GUAs.

Anycast Addresses

An anycast address is an identifier for a set of interfaces, belonging to different nodes. A packet sent to an anycast address is delivered to one of the interfaces identified by that address. The interface chosen is considered the nearest, according to the routing protocol's distance measurement.

Use cases for anycast addresses include load balancing and efficiently distributing data among the nodes in a network. As an example, if a router fails, IPv6 nodes may establish a connection to a fail-over router, using a defined anycast address, and maintain the availability of the network.

Anycast addresses are indistinguishable from unicast addresses.

Multicast Addresses

A multicast address is an identifier for a set of interfaces typically belonging to different nodes. A packet sent to a multicast address is delivered to all interfaces identified by that address. Multicast addresses are present in the address space: FF00::/8.

There are no longer IPv4 broadcast addresses in IPv6. A broadcast address is used to transmit network information, such as DCHP and ARP, to all hosts on a network segment. IPv6 subnetworks are designed to be substantially larger and broadcast traffic becomes in-efficient at this scale. Their function has been replaced by multicast addresses.

Well-Known Multicast Addresses

There exists an address registry, managed by IANA, covering well-defined multicast addresses for standardized topics such as:

• The all routers group (FF01::2)
• The all nodes group (FF01::1)
• The Multicast DNS (mDNSv6) group (FF01::FB)

Multicast Listener Discover

Multicast Listener Discover (MLD) is used to join and listen to multicast traffic. Devices send MLD reports on groups that they would like to join. Routers receive the reports and build multicast tables associated with the addresses. When the router receives multicast traffic, it is responsible for forwarding to the individual interfaces.

Thread - A Use Case for IPv6 Address Types

We are seeing applications and standards utilizing these different types of addresses for optimizing the flow of traffic. For example, Thread, an open IPv6-based networking protocol for Internet of Things (IoT) devices, uses these address types for the operational communication of connected smart devices.

• Multicast messages define and allow control of connected groups of nodes and allow devices to announce themselves on the network for service discovery.
• Anycast messages determine the closest router to a particular node in a Thread mesh network. In addition, anycast addresses allow fault tolerance. If a router becomes unavailable, a new router is established and connectivity is maintained.

Subnetworks in IPv6

The recommended size of an IPv6 subnetwork is 64 bits. This allows for 2⁶⁴ individually addressable hosts within the subnet. This is substantially larger than IPv4 and in fact, a single IPv6 subnetwork can contain the entire address space of IPv4.

The vastness and consistent size of IPv6 subnetworks have many benefits including:

• They support the future growth of IoT devices by significantly increasing the number of local connections available.
• They make it easier for network engineers to manage and move subnetworks.
  • There will be a less likely chance of host address collisions when connecting large organizational networks.
• Being less feasible for attackers to use network probing techniques that sequentially scan to find open services for attack, as talked about in RFC 5157.

Network Prefix Sizes

A "Prefix" is a defined range of blocks in the IPv6 address space beginning with the left-most bits. As an example, 2001:0db8:1234::/48 indicates that the first 48 bits, 2001:0db8:1234, are for the global routing prefix. The remaining 80 bits can be divided by the assigned part to delegate to routers for subnetworks and host addressing.

Internet Service Providers (ISPs) are recommended to provide an IPv6 prefix of at least /56 to homeowners and a /48 for organizations. Given these prefix sizes and the recommended IPv6 subnetwork size of 64 bits, we can calculate the total subnets available to each.

• A homeowner receiving a /56 prefix could create 2⁸ individual subnets.
• An organization receiving a /48 prefix could create 2¹⁶ individual subnets.

64-bit Extended Unique Identifier (EUI-64)

The interface identifier (IID) is the grouping of the right-most 64 bits of an IPv6 address. It is not meant to be contiguous but instead, each client generates their unique identifier.

You may be aware of IEEE 802 MAC addresses, which are globally unique identifiers assigned to all commercial networking hardware. These identifiers have been used since the early adoption of Ethernet and standardized as part of IEEE 802.3. While these 48-bit addresses allow for a large number of unique identifiers, the standard is projected to have an end-of-life by 2080.

IPv6 has adopted the EUI-64 standard, which provides an increased 64-bit capacity and is derived from a MAC address using a straightforward process. We will look at alternatives to generating 64-bit IPv6 interface identifiers to preserve privacy in the sections below.

Dynamic Host Configuration Protocol (DHCP) Version 6

The fundamentals around DHCPv6 are different when compared with its DHCPv4 predecessor. The biggest change is that a DHCPv6 service is no longer required to be run on each network segment to coordinate host addressing. A DHCPv4 service was required to be present and be the source of truth for host address reservations in IPv4. On the other hand with IPv6, clients can generate addresses from self-assigned identifiers using what is known as Stateless Address Autoconfiguration (SLAAC).

The primary responsibility of DHCPv6 is to provide a mechanism for delegating IPv6 prefixes to other routers, as defined by DHCPv6 Prefix Delegation (DHCPv6-PD). A requesting router acts as a DHCP client and requests a prefix to be assigned by a delegating router, acting as a DHCP server.

As part of recommendations for DHCP-PD, delegated prefixes should have an indefinite lifespan. It can be costly to renumber an entire site when provided a new prefix, as each router must reconfigure their DHCP prefix settings and hosts must reconfigure their addresses. ISPs are encouraged to assign customers persistent prefix assignments which would not require renumbering.

Stateless Address Autoconfiguration (SLAAC)

SLAAC is often used as a means for obtaining IPv6 addresses, especially for link-local. The following steps are executed by a device to set up an IPv6 stack using SLAAC:

1. The device generates an EUI-64 and with it, a link-local address.
2. The device executes Duplicate Address Detection on the network segment. If a duplicate address exists, the device will restart the process.
3. A Router Solicitation (RS) is sent and a Router Advertisement (RA) is received to obtain the router prefix information.
4. The device creates a Global Unicast Address (GUA) using the prefix provided by the router by executing steps 1 and 2 with this new address.

At this point, the device can communicate with neighbors on the network segment and globally through the IPv6 router advertised.

SLAAC allows for simplified network configuration as stateful services, like DHCP, are no longer necessary to run an operable network. Devices can automatically configure their addresses and communication can take place throughout the networking segment.

Advertising DNS Configuration

RFC 8106: IPv6 Router Advertisement Options for DNS Configuration

This document specifies IPv6 Router Advertisement (RA) options (called “DNS RA options”) to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.

IETF DatatrackerJaehoon Paul Jeong

To support IPv6 SLAAC deployments without requiring a DHCPv6 server running on each subnetwork, a mechanism was introduced to provide DNS configuration as part of the Router Advertisement (RA). Domain information, such as RDNSS and DNSSL, may be included in the RA messages to inform hosts of this critical domain information.

End-to-End Routing

Due to the anticipated depletion of IPv4 addresses, Network address translation (NAT) was introduced. This routing technique allows a single public IPv4 address to map to multiple local devices on a private network. When a local device connects to an external resource, a router must keep track of the connection state and context, and translate incoming and outgoing communication between the devices.

With IPv6, NAT is no longer required. Every single connected device can receive a unique and publicly accessible IPv6 address. Thus connections are truly end-to-end and no translation by the router is needed. In its purest form, every host can directly communicate with another host through its IPv6 address, barring any firewall restrictions between the two hosts.

Neighbor Discovery Protocol (NDP)

The Neighbor Discovery Protocol (NDP) is fundamental in IPv6 routing and discovery processes. It is used to perform several important tasks such as:

• Router discovery to solicit and advertise routers on a network segment.
• Address resolution to locate neighboring hosts on a network segment, for Duplicate Address Detection and IP to MAC address translations.

Similar to IPv4 ARP, NDP is used to translate IP addresses with some added benefits that can prevent the security shortcomings of ARP. For example, ARP spoofing can be mitigated by what is called Secure Neighbor Discovery (SEND).

IPv6 Security Guidelines

Security was a fundamental design consideration of IPv6. In fact, IPSec is considered a node requirement for all IPv6 implementations, though it must be enabled on both device and application to use.

Some additional security considerations should be noted and may require extra configuration on network and end devices which we will go over below.

A Firewall is Required

Without Network Address Translation (NAT), IPv6 hosts are directly addressable to hosts outside the network. This fact makes packet switching and routing much simpler and as the Internet had originally been designed for, by way of the end-to-end principle.

That being said, this may cause unintended side effects as hosts on a network designed in a way that assumes hosts would not be publicly addressable may find their hosts exposed directly to the Internet, bad actors, and more when switching to IPv6.

For these reasons, a firewall must be enabled on an IPv6-enabled router and should be configured in such a way that blocks unintended incoming traffic to its hosts.

Increased Security Through Privacy Addresses

The IPv6 addressing architecture defined that the rightmost 64 bits, associated with the interface identifiers (IID), be derived using an interface's MAC address, defined as modified EUI-64 format. This poses security concerns as a MAC address is globally unique and could be used to track an individual. Another security concern is that this could allow an attacker to find vulnerable targets, as MAC addresses can identify specific types of manufactured hardware.

One simple way around this is to generate a random MAC address. The Android operating system implements MAC randomization for each network it connects to. The randomized MAC address can be used to generate an EUI-64 without privacy concerns.

Another way to enhance device privacy is to use Privacy Extensions for SLAAC. Privacy extensions define a mechanism for devices to create temporary addresses using randomized interface identifiers. These addresses are only used for outgoing connections and have a limited lifetime and are rotated periodically, usually 24 hours.

The currently recommended way of creating stable IPv6 interface identifiers, while preserving the privacy of devices, is to use Stable Privacy Addresses defined in RFC 7217. These addresses are created from a hashing function using inputs such as a device generated secret key and the network prefix. This type of stable address remains the same unless it moves to a new network or the network prefix changes.

With all of these different methods of creating the 64-bit interface identifier, the bits representing the identifier lose meaning and so it is recommended that the identifier be considered opaque.

Unauthorized Link-local Addressing

IPv6 traffic may be happening between hosts through link-local addressing even if a network admin has not explicitly set up IPv6 on their network. IPv6 and link-local addresses are auto-configured by the hosts themselves.

One consequence of this is that there may be unintended communication between hosts on a network segment if they are IPv6 enabled. IPv6 and IPv4 addresses should always be considered when defining firewall rules and network Access Control Lists (ACLs).

VPN Leakage for Dual-Stack Environments

A client that supports both IPv4 and IPv6 and relies on VPN connectivity to maintain anonymity, should always make sure that IPv6 is enabled on the VPN client. If the VPN tunnel lacks support for IPv6, the client may inadvertently leak IPv6 traffic outside of the tunnel breaking the user's anonymity.

Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks

The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over a VPN connection may leak out of such connection and be transferred in the clear on the local network. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned issue.

IETF DatatrackerFernando Gont

If the network the client is connected to does not support IPv6, one should still enable IPv6 on the VPN client and black hole all IPv6 traffic. This is done by ProtonVPN as a preventative measure against leakage.

Unique Local Addressing (ULA) and NAT

Network admins may consider, when transitioning from IPv4 to IPv6, keeping the fundamentals of NAT in place within their private networks. Unique Local Addresses (ULA) were defined in IPv6 standards as a block of addresses accessible site-wide and not meant to be routed to the global address space. This would allow NAT66 to map a Global Unicast Address to an internal ULA address.

As explained in this Infoblox article, usage of ULA is fundamentally flawed within a dual-stack environment since IPv4 will always take precedence over ULA addresses. So the IPv6 stack would never be utilized over the IPv4 counterpart.

In conclusion, it is advised to design an IPv6 network around Global Unicast Addresses and not continue with the necessary designs and mindsets commonly used due to the limiting factors of IPv4.

Rogue IPv6 Router Advertisements

Routers on an IPv6 network advertise information to nodes that enable them to auto-configure and connect to their network. Rogue IPv6 router advertisements may be sent to nodes, whether maliciously or by misconfiguration, which could lead to Man-in-the-Middle attacks or general network routing issues.

A similar situation can happen in IPv4, where rogue DHCP servers may be on the network. DHCP snooping can be deployed on layer 2 switches to help combat and secure networks for this IPv4 scenario. An equivalent mechanism, called RA-Guard, can be used for IPv6-enabled routers on layer 2 switches to help detect and mitigate rogue routers on the network.

Neighbor Discovery Protocol (NDP) Attacks

Duplicate Address Detection (DAD) is integral to the functioning of SLAAC. DAD may be exploited by malicious actors for denial-of-service attacks on a network segment. When a node queries with a Neighbor Solicitation to determine whether an address is being used, the malicious attacker may repeatedly respond causing the node to continually reject addresses and be unable to connect to the network. Similarly, an attacker may try to flood routers with NDP queries, causing legitimate traffic to be disregarded or the router's Neighbor Cache to be overloaded.

Secure Neighbor Discovery (SEND) can be used to mitigate these types of attacks. SEND must be enabled on each device, which includes steps like creating public keys and associating Cryptographically Generated Addresses (CGAs). I have not found any operating systems that support this out of the box and only a few third-party concepts are available for use at the time of writing. Bootstrapping each device to mitigate these types of attacks would be very difficult as well.

Alternatively, routers may rate limit the amount of NDP queries that can be sent over a particular time frame.

It should be noted that IPv4 has the same types of attack vectors through ARP. This Infoblox blog article goes over steps an admin can do to secure both protocols but concludes that this is an avenue that requires more thought and consideration to secure.

The Adoption of IPv6

We have seen that there are benefits to switching to IPv6, such as the increase in address space, simplified networking configuration by not requiring a running DHCP server for each subnetwork, and enhanced support for multicast and anycast traffic that allow for innovations in IoT systems.

That being said, the adoption of IPv6 has been slow. Standards for IPv6 were first introduced in 1995. According to the most recent adoption by country statistics reported by Akamai (as of June 2024), only a handful of countries have greater than 50% adoption rates, with the majority of countries having significantly lower rates.

The reasons for the slow adoption are complex. Resources on the Internet will want to be able to reach the most amount of users possible. The current Internet is dominated by IPv4 users, so it makes sense that services will prioritize IPv4 to maximize their reach. In addition, organizations and customers require that their cloud providers or ISPs provide them with sufficient prefixes and support for IPv6 utilization. On top of that, hardware vendors and networking software must be IPv6 aware to support it at every hop.

Some recently passed initiatives will accelerate the adoption of IPv6. The US Government has put policies in place to completely transition to IPv6-only deployments by 2025. It is recognized that IPv6 is the future and the government wants to fully transition its resources to IPv6 and minimize the impact of running dual-stack environments.

As the number of addresses in the IPv4 space dwindles, the cost of owning and allocating them is increasing. As of February 1st, 2024, AWS has started to charge tenants per public IPv4 address allocated to their resources. Supply and demand will dictate the price for these addresses. Organizations will begin to see higher operational costs for IPv4 which may push them to begin transitioning their environments to IPv6.

Conclusion

We have covered many areas around the IPv6 architecture and looked into differences between it and its predecessor, IPv4. In doing so, realizing that it is straightforward and allows for true end-to-end networking, as the Internet had originally intended. We have looked into use cases for the different address types and how they can make for more efficient and reliable routing of our data. Finally, we've looked into how to secure deployed IPv6 networks.

As IPv6 becomes increasingly adopted, we will see some more benefits and greater innovations further fueling the push to switch to the newest protocol. I for one am getting up on the bandwagon to welcome our new digital messiah!