IPv6

Background

Internet Protocol (IP) provides the base packet transport mechanism for the public Internet and, these days, also for most private IT networks. Internet Protocol was developed in the 1960s and 70s, with version four (IPv4) being the first standard (documented in RFC 791) in 1981.

Motivation for IPv6

By 1990, it was already clear that enhancements to IP were needed to support the ongoing growth of the public Internet, with RFC 1883 being the first to describe IPv6 published in 1995 and the first standard adopted in 1998 (in RFC 2460). The main changes, compared to IPv4, that are included in the IPv6 specification are as follows:

  • Expanded Addressing.  IPv6 addresses are 128 bits in length, providing over 340 undecillion addresses.
  • Header Format Simplification.  Where IPv4 has a variable length header (between 20 and 60 bytes). IPv6 has a fixed 40-byte basic header. Further, IPv6 does not include IPv4’s Header Checksum field, saving computational effort at every router hop.
  • Improved Support for Extensions and Options.  IPv4 has a single Options field in the packet header, IPv6 has the concept of Extension Headers to support extensible optional elements without redesigning the protocol.
  • Flow Labelling.  Although not yet widely adopted in practice, the IPv6 Flow Label allows a sender to identify a group of packets that need to be given special treatment by routers. The characteristics of the treatment may be defined in other Extension Headers, but the Flow Label can be used by routers to cache the treatment rather than having to process the Extension Headers for every packet in the group.
  • Improved Security.  The original IPv6 specification includes network layer IP Security (IPsec) as a mandatory capability. RFC 6434 has loosened this to a recommendation, reflecting the use of other security mechanisms, such as TLS and SSH, and the fact that “achieving security in practice is a complex undertaking”.

Although the effect of these changes improves the scalability, efficiency and functionality of Internet Protocol, the fact that the packet format is different to IPv4 means that hosts using the different versions cannot communicate directly, and this has been the cause of practical delays in its adoption.

Since the allocation of public IPv4 addresses by the Regional Internet Registries has ceased, Internet Service Providers now get these address blocks through a marketplace of IP address brokers. IPv4 addresses typically cost around $50 each, adding significantly to the cost of providing IPv4-based Internet services and providing a further incentive for ISPs to offer IPv6-based services.

Slow Adoption of IPv6

Despite the improvements offered by the above revisions to Internet Protocol, the adoption of IPv6 has been slow: with Google’s IPv6 Adoption tracker showing 43% globally at the time of this writing in 2024, more than 25 years after the protocol was first standardized.

The main reasons for this are:

  • No Specific Imperative.  “Workaround” solutions to address shortcomings in IPv4 have been very successful. These include Dynamic Host Configuration Protocol (DHCP), Network Address Translation (NAT), and IPsec as an overlay on TCP/UDP. NAT, in particular, has significantly extended the use of IPv4 by allowing the devices in a private enterprise or domestic network to share a single public IP address at the point of connection to the Internet. Consequently, and particularly where Internet connectivity using IPv4 already exists, there hasn’t yet been an IPv6-only application that has driven faster adoption.
  • Considerable Migration Effort Is Needed.  The practicalities of migrating to IPv6 go beyond simply enabling it in the network. Existing applications need to be individually assessed to verify that they operate correctly, and the migration of associated backend systems and support tools needs to be co-ordinated. During the migration, which may be lengthy depending on the scale of the organisation, it might be necessary to implement additional tools, equipment or network configuration to support the process.

Platform and Operating System Support

Regardless of the practical challenges in IPv6 adoption, network equipment and operating system manufacturers have continued to develop IPv6 capabilities in their implementations. In almost all cases, IPv6 features operate in addition to an existing IPv4 implementation, enhancing the dual-stack approach to IPv6 deployment.

A list of IPv6 capabilities in major operating systems is on Wikipedia: Comparison of IPv6 support in operating systems. Whilst this list is not exhaustive, it demonstrates that, at a technical level, a dual-stack IPv4/IPv6 network, including network devices, application servers and clients using the most common operating systems is practicable.

Further, most popular operating systems support the principle of using IPv6 as their first choice IP transport protocol if it is available, with fall-back to IPv4 where necessary.

End-User IPv6 Address Management

The RIPE Network Co-ordination Centre provides guidance on the subnet layout for IPv6 address allocations to end-users, whether they’re businesses or domestic customers. This guidance is documented in their Best Current Operational Practices (BCOP) document, ripe-690.

The guidance recommends that each customer receives a delegated public IPv6 address block of at least /56 size, with larger customers receiving a /48 block. This allows any customer to have a local network with a minimum of up to 256 subnets and with each subnet having a /64 block.

The /64-per-subnet requirement comes from the Stateless Address Autoconfiguration (SLAAC, RFC 4862) feature of IPv6. The original intent of SLAAC was that a device could use its Layer 2 MAC address as the basis for the host portion of its IPv6 address within a /64 subnet. By receiving the prefix portion of the IPv6 address in an announcement from a router, a host can then configure its public IPv6 address without needing a mechanism such as DHCP.

Obtaining DNS Parameters

Given that the Domain Name Service (DNS) is integral to the practical operation of IP-based network services, a means to allow hosts to obtain their DNS parameters is needed to work alongside SLAAC as part of the host auto-configuration process.

IPv6 Router Advertisement Options for DNS Configuration (RFC 8106) provides this capability by adding the IPv6 addresses of DNS servers and the domain search list into the Router Announcement (RA) messages included in the IPv6 Neighbour Discovery (ND) protocol. This capability is often known as RDNSS, after one of the option fields (the Recursive DNS Server option) defined in RFC 8106.

Implementation

A common layout for an enterprise or domestic network connected to the public Internet using IPv4 is as shown below.

The key elements of this layout are:

  • An Edge Router/Firewall provides the boundary between the public Internet and the private enterprise or domestic network. Private IPv4 addresses (RFC 1918) are used in the private network with NAT translating multiple private addresses into a single public IPv4 address. In the domestic configuration the edge router/firewall usually has a single IPv4 address. In the enterprise, a larger block of addresses might be used: this reflects the potential requirement for more externally accessible systems using public addresses.
  • The public IPv4 address(es) are assigned to the Edge Router/Firewall using either DHCP or static configuration. Most domestic Internet services don’t include a specific assigned IPv4 address, so use DHCP. In practice, modern broadband services, with their “always on” characteristics, often retain the same IPv4 address through the DHCP renewal process.
  • Some providers offer a static public IPv4 address assignment as a paid add-on to the Internet service though this is often delivered via DHCP in practice.
  • The Edge Router/Firewall often acts as a DHCP server for the private subnets.

A feature of this arrangement is that to allow incoming connections from the Internet to systems in the private network, the Edge Router/Firewall needs to be configured with Port Forwarding rules that define how this traffic should be routed.

For example, in the diagram the private network includes a DMZ subnet with a Web Server that needs to be reachable from the public Internet. To achieve this, the Edge Router/Firewall would be configured with a rule that forwards traffic with a destination address of 203.0.113.47 and port 443 (HTTPS) to 192.168.2.50 and port 443. If external access was also required to the Media server, a second port forwarding rule, using a different port number, would be needed: for example, traffic with a destination address of 203.0.113.47 and port 8443 forwarded to 192.168.1.100 port 443.

The combination of port management, configuration, support and processing overhead represents one of the hidden costs of operating an IPv4-based connection to the public Internet.

An equivalent network layout using IPv6 is shown below.

The key elements of this layout are:

  • The Edge Router/Firewall continues to provide the boundary between the public Internet and the enterprise or domestic network but there is no need for NAT since every device can have a public IPv6 address. In this case firewall rules control the flow of traffic into and out of the enterprise or domestic network.
  • The Edge Router/Firewall typically uses DHCPv6 with the serving ISP to obtain both the IP address for its external connection and a delegated IPv6 prefix that it can use to assign addresses to internal subnets. In this example, a /56 prefix (2001:db8:7e13:2f00::/56) allows 256 internal subnets, each with a /64 prefix, to be assigned by the Edge Router/Firewall (2001:db8:7e13:2f00::/64 to 2001:db8:7e13:2fff::/64).
  • No DHCP server is needed in the enterprise or domestic network since the SLAAC and RDNSS mechanisms can be used for device autoconfiguration. In practice, an enterprise might choose to use a dedicated DHCP server to gain closer administrative control over the end-devices connected to its network.
  • No port forwarding function is needed in the Edge Router/Firewall since every device in the network can have its own public IPv6 address.

Conclusion

The stability, maturity and completeness of the IPv6 capabilities in modern network equipment and host operating systems enables the implementation of a dual-stack IPv6/IPv4 network. More ISPs are implementing IPv6 as part of their access services to customers and more content hosting providers are including IPv6 alongside IPv4. The tipping point to the widespread adoption of IPv6 may be coming soon.