Introduction
As you may know, IPv4 is the main protocol used to communicate on the internet today. Its chief limitation is the size of its address space, a function of IPv4 addresses being only 32 bits long. This gives a theoretical maximum of 4,294,967,296 addresses to work with, though the practical number available for conventional unicast communication is lower because approximately 290 million addresses were set aside for multicast, reserved, and private address ranges.
The IPv4 address space was large when the internet was created, but that was decades ago. We have now essentially reached the point of IPv4 exhaustion, with almost all addresses assigned. For example, in November 2019, RIPE NCC assigned its last /22 IPv4 block.
Attempts to deal with the exhaustion problem have included efforts like network address translation (NAT), where one public IPv4 address is multiplexed to serve hundreds or thousands of hosts NATed behind it. However, this is a workaround; the real fix is the deployment of IPv6, which offers 2128 addresses along with many other benefits.
In this article series, we’ll discuss the benefits of IPv6’s increased address space and many other reasons why IPv6 is a superior protocol and you should consider its adoption — not only for your public IP addressing but in your internal networks as well.
Current state of IPv6 deployment
The global transition to IPv6 is borne of necessity, and today we find approximately 40% adoption across the globe, on average, with some differences among networks, countries, and regions. A good resource to see the latest statistics is Google’s IPv6 statistics page.
Many organizations have successfully moved to single-stack IPv6-only networks internally, considering IPv4 to be a legacy protocol required only for public-facing applications and devices.
Summary of IPv6 benefits
Here is a list of IPv6 benefits that will be further explained below.
Increased address space
IPv6 uses 128-bit addresses for a total address space of 2128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses, or around 340 trillion trillion trillion (340 undecillion). Currently, “only” 42 undecillion addresses have been assigned by IANA for global routing, but even that is an astronomical number. The huge IPv6 address space ensures future support for mobile networks, content networks, IoT applications, and anything else requiring IP addresses.
{{banner-13="/design/banners"}}
Simpler header
IPv6 has 8 header fields versus IPv4’s 13 fields. The diagram below shows clearly how they compare:
This simplification makes packet analysis simpler and the results easier to understand, and there may be some performance gains due to easier header processing in ASIC hardware. The simpler structure certainly means fewer fields to inspect and handle in policy when configuring network devices. The motivation for simplifying the standard header format was eliminating fields that were rarely used or not needed. Later in the article, we will cover the new Flow Label field and an important IPv6 header feature: modular extension headers.
More efficient packet processing
The IP checksum has been removed from the IPv6 packet structure, so routers and hosts no longer need to constantly recalculate checksums for every packet forwarded. Instead, Layer 2 switching and Layer 4 transport protocols handle this via fields such as the Ethernet CRC or TCP checksum. This simplifies the protocol implementation for all network nodes and reduces computational overhead.
More efficient routing
IPv6 increases the use of summary routes and hierarchical routing. One problem with IPv4 addressing is that as the utilization of available space approaches saturation, IPv4 address leasing has become a booming industry, resulting in the address space being heavily disaggregated into distinct /24 subnets. For example, many networks are unable to announce a summary route of /21 because their IP space is fragmented across multiple /24 networks. This has caused an explosion in the sizes of routing tables.
In contrast, IPv6 address space is being allocated sensibly, generously, and with lots of room for future growth. Networks are able to announce a small number of summary routes to cover their address spaces, keeping routing tables small and helping with performance and route convergence.
In fact, compared to IPv4 — where space allocated by one regional internet registry may end up used in another part of the world — assigned IPv6 addresses are more closely aligned to their local regional internet registries. Summary routes can often pinpoint their geographical locations, and due to hierarchical sub-allocation and assignment, it is possible to infer more information from an IPv6 route by looking at the first few bits.
{{banner-9="/design/banners"}}
Elimination of router-based fragmentation
In IPv6, packet fragmentation and reassembly are handled by the sender and receiver. This is a change from IPv4, where packet fragmentation is handled by every transit node (router) on the path as necessary.
In IPv4, fragmentation incurs a performance hit on intermediate nodes, which must fragment the packets and mark the fragments. In IPv6, the sending node probes the receiver to discover the path maximum transmission unit size (MTU) and uses this to perform any fragmentation needed, with the receiver then reassembling fragments. All the hops along the path are spared from fragmentation issues. If the first-hop node receives a packet that’s too large, it sends an ICMPv6 error message back to the sender rather than fragmenting. This concept is sometimes referred to as “end-to-sender” fragmentation.
Directed multicast instead of broadcast
Instead of broadcasting to all nodes on a Layer 2 domain, directed multicast is used, which conserves bandwidth and node resources because only the relevant nodes must process these packets.
The most obvious example of the change here is link-layer neighbor address discovery, which is required to deliver traffic on the local link and/or Layer 2 broadcast domain. In IPv4, this functionality is delivered via the address resolution protocol (ARP): Requests such as “Who has IP 10.0.0.1?” are sent out as broadcasts to all nodes in the Layer 2 broadcast domain (or subnet). Replies are sent as unicast frames, e.g., “I have this IP address, and my MAC address is aa:bb:cc:dd:ee:ff.” This is how hosts learn unknown Ethernet MAC addresses for known IPs, but they must broadcast to all devices to do it.
IPv6 does not have ARP and instead uses neighbor discovery (ND), which you can read more about here. Requests (Neighbor Solicitation messages) are sent as directed multicasts, while replies (Neighbor Advertisement messages) are sent as unicast responses. This is more efficient than using broadcasts.
IANA has reserved the address range ff00::/8 for multicast, with ff00::/12 reserved for “well-known” multicast addresses and other ranges used for specific purposes. Some examples of well-known address ranges include:
- ff02::1: All IPv6 devices
- ff02::2: All IPv6 routers
- ff02::5: All OSPFv3 routers
- ff02::a: All EIGRP (IPv6) routers
Security enhancements
For starters, the IPv6 address space is so large that it inherently provides enhanced security as a useful side-effect: A vastly larger address space creates obscurity that makes port scanning more difficult. There are some hacks, such as sending malformed packets to well-known multicast addresses to elicit a response from live hosts, thereby revealing nodes. However, IPv6 multicast is sparsely deployed on the internet, so due to a lack of implementation and various security policies, this type of port scanning is difficult to achieve online.
IPSec integration is baked into IPv6 through the use of extension headers, which are mandatory for IPv6 implementations. This ability to use extension headers allows for the more seamless deployment of IPSec over IPv6; in contrast, IPSec over IPv4 is an “add-on.” The new extension headers for security and their protocol numbers are:
- 051: Authentication header
- 050: Encapsulated security payload
Further reading on extension headers can be found on this Cisco page.
QoS enhancements
Traffic Class is an 8-bit field used to mark packets for specific QoS handling. In effect, this field is equivalent to the IPv4 ToS/DiffServ field, where 6 bits are used for DSCP values and 2 bits for congestion notification. (Per RFC8200, “the current use of the Traffic Class field for Differentiated Services and Explicit Congestion Notification is specified in RFC2474 and RFC3168”.)
Flow Label is a 20-bit label uniquely identifying traffic flows between a given source and destination and is applied by the sender. Devices along the path can identify packets in a given flow using this label to ensure consistent packet-order delivery and QoS handling.
Auto-addressing features
There are two main methods of addressing within IPv4: Static assignment via a manual process or using a DHCP server to manage assignment and prevent IP address conflicts. Manual address assignment often makes use of an IP address management (IPAM) tool or spreadsheet to manually assign and configure IP addresses and keep assignment information up to date.
Of course, manual processes can be labor-intensive and error-prone. IPv6 was designed with features to ameliorate the many difficulties associated with determining host addresses under IPv4.
{{banner-10="/design/banners"}}
Link-local address determination
You can connect IPv6 hosts on a LAN without a router or DHCP server and use IPv6 auto-addressing to enable easier peer-to-peer networking. This has use cases, particularly in home LANs that contain consumer-friendly smart TVs, CCTV systems, and the like.
The convenience of auto-addressing in the absence of any router or DHCP server configuration allows for touchless plug-and-play setup of small LANs and even commercial LANs using large sensor networks, for example. Hosts can discover each other using the well-known multicast addresses and neighbor address discovery, as discussed above.
SLAAC: Stateless Address Autoconfiguration
This IPv6 feature allows groups of hosts to statelessly autoconfigure themselves with unique global unicast addresses, so they can communicate online. This is done without the use of a server or stateful assignment (as in DHCP) but does require the presence of an IPv6 gateway router. As part of the process, hosts perform duplication detection and resolution, and they make use of Router Solicitation messages (part of the Neighbor Discovery protocol) to determine their globally unique global unicast addresses.
No more NAT*
NAT is generally no longer needed or recommended when using IPv6 since there is no shortage of IPv6 address space. On the IPv6 internet, direct end-to-end connectivity is restored, reducing complexity in network administration, application design, and processing overhead within network elements.
A side-effect of stateful source NAT with port overload is that unsolicited connections from “outside” are rejected or dropped by default. This is because unless the inside host initiates a NAT session to connect to an outside host, there will be no stateful firewall rule to permit traffic inbound. This can indeed protect hosts behind the NAT, but it is a myth that the absence of NAT means a reduction in security. The idea that NAT adds security is conflating two things: NAT is an addressing function, while stateful firewalling/packet inspection is a security function. Without NAT, you can achieve the same protection with stateful firewalling and less complexity.
* RFC4864 outlines many reasons why NAT is no longer required for IPv6. That said, IPv6 NAT can be used for specific applications if truly desired, for example, NAT66 RFC6296.
Carrier-grade NAT (CG-NAT) was and still is used as a workaround for IPv4 address exhaustion. Its key disadvantages include the following:
- Expensive router/firewall hardware resources must maintain huge volumes of stateful NAT sessions — hundreds of thousands of connections per second.
- Complexity in administration increases the risk of misconfiguration.
- It breaks the end-to-end principle, effectively breaking many kinds of applications such as P2P games and torrent clients. This is because port forwarding is not enabled by default: The carrier will allow outbound connections from the client and associated return traffic, but it will not port-forward to allow inbound connections. There are further workarounds for this, such as the Port Control Protocol RFC6887. However, as the complexity mounts with workarounds upon workarounds, it becomes more clear that IPv6 is the superior option overall.
{{banner-sre="/design/banners"}}