Skip to main content

Technology standards: Understanding IPv6

The world ran out of IPv4 addresses several years ago. Even though the sky didn’t fall, concern for your organization's future requires that you plan for IPv6 adoption. There are no more excuses.

The main network protocol of the Internet, and just about all other networks these days, is Internet Protocol (IP). Most of the Internet uses IP version 4 (IPv4), the first definition of which dates back to 1981. IPv4 has done its job admirably, but the Internet has outgrown it.

IP version 6 (IPv6) has also been around a while, but it was designed with a much more ambitious view of the scale of the Internet and to incorporate the lessons learned while growing the IPv4 Internet.

Running out of room

When IPv4 was designed in the 1980s, originally as a research project of the Defense Advanced Research Projects Agency (DARPA), the Internet was still the province of computer engineers, scientists, and other relatively small groups. So, when DARPA chose a 32-bit value for the maximum number of devices, with a maximum value north of 4 billion, the computer scientists must have figured it was future-proof. And if it needed to be changed, big deal. They would just change it.

The Internet designers were wrong on both counts. By the early 1990s, it was clear to those in charge that the growth of Internet use would exhaust the address pool before too long. They began work on a protocol upgrade and, in the meantime, invented tricks like the Network Address Translator (NAT) to let users make do with fewer Internet addresses.

The first iteration of the new protocol was known as IP Next Generation (IPng) and defined in RFC 2460. Over the years, this definition was updated by nine other RFCs in order to address issues with the initial protocol, so the IETF decided to obsolete RFC 2460. The current version of IPv6 is defined in RFC 8200, which was made official in July 2017.

IPv4 addresses are 4 bytes (sometimes called octets) long and represented with dots in between, as in

As they are bytes, each value can range from 0 to 255. Ranges of addresses are assigned to specific parties. You can see all the assignments here. Each of these allocations is for all addresses beginning with a particular byte value from 0 to 255, so each is 1/256 of the entire IPv4 Internet, a very large chunk of virtual space. The U.S. Department of Defense owns several large ranges (in fairness, it was paying for it all, early on). A few others are owned by ISPs—such as Level 3, Cogent, and AT&T—and two others by Ford Motor Co. and Apple.

In the early days, before the scarcity of addresses was appreciated, it was extremely easy to reserve large blocks of addresses. In recent years, most of these massive allocations to private bodies have been surrendered, at least in part, to the regional Internet registries. If you look at the allocation list from late 2013, you see blocks assigned to General Electric, IBM, DuPont, MIT, and even Hewlett-Packard.

A block such as this is known now as a “/8” network, meaning it contains all addresses in which the first 8-bit byte have a particular value. A /24 network has only one variable byte and, therefore, 256 addresses in it. This is called Classless Inter-Domain Routing notation, and it is used in IPv6 as well. CIDR was introduced in the early 1990s to make routing tables more efficient.

Many other /8 and smaller ranges are reserved for specific technical functions. You might recognize some of these:

Private network

Usually allocated internally with DHCP and connected to the Internet through NAT.


Addresses the local host, i.e., the same computer from which it is sent.

Link local

An automatically configured address for the local network only.

Carrier-grade NAT

Private network for large ISPs.

Many IPv6 ranges are allocated for these and similar functions.

IPv6 expanded addressing

IPv6 addresses have 128 bits (16 bytes), greatly expanding the depth of address hierarchy and the overall number of addresses. This is an address space so vast that we may just take it with us to the first few planets we colonize. IPv6 addressing architecture is defined in RFC 4291.

To write an IPv6 address in text, we group pairs of bytes (a field) using hexadecimal and separate them with colons. For example: ABCD:EF01:2345:6789:8765:4321:0FED:CBA9

There are a number of shortcuts that can usually save a few characters. For instance, you can skip leading zeros in each field, so 2001:DB8:0:0:8:800:200C:417A is the same as 2001:0DB8:0000:0000:0008:0800:200C:417A.

It is common, as in this last address, to have consecutive fields with only zero bytes in them. Only once in an address can you replace such a sequence with empty colons, and so this address is also equivalent to the previous two: 2001:DB8::8:800:200C:417A.

This can often make addresses quite short, and so the loopback address 0:0:0:0:0:0:0:1 can be written as ::1.

Unicast, anycast, and multicast addressing

IPv6 addresses are either unicast, anycast, or multicast. A unicast address is associated with exactly one interface, which usually means a network interface on a computer. That interface may have many multiple unicast addresses associated with it.

An anycast address is a set of interfaces; data sent to an anycast address is delivered to one of these interfaces, the "closest," according to the routing protocol.

IPv4 has broadcast addresses. Data sent to the address is received by all addresses on the subnet. In IPv6, this function is replaced by multicast addressing. A packet sent to a multicast address is delivered to all interfaces with that address.

There are also special addresses. For example, the unspecified address 0:0:0:0:0:0:0:0——which also can be written as ::——is used in a few specific cases, such as the source address for an interface that has not yet learned its own address. Routers do not forward packets with the unspecified A=address as a source or destination.

There is also the loopback address, 0:0:0:0:0:0:0:1, which can also be written as ::1. It is analogous to in IPv4. A packet sent to it is delivered back to the interface that sent it.

From v4 to v6

Many efforts were made to ease the transition from IPv4 to IPv6, but these things are never as easy as we would like. 

Where possible, the best mechanism is a dual-stack implementation, meaning to configure a device or interface to support both IP versions. If the configuration has IPv6 as the preferred protocol, then it should be increasingly used as adoption of IPv6 increases generally. The day may come when the IPv4 address is extraneous; we should live so long.

Innovation in your in-box. Sign up for our weekly newsletter.

In the meantime, all important Internet protocols and almost all important application software support IPv6. For instance, DNS stores IPv4 addresses as A records and IPv6 addresses as AAAA records. When all the other protocols on your networks are IPv6-enabled, which is the default on all modern operating systems, you can migrate the application layer.

One benefit of the massive address space of IPv6 is that it drastically reduces the need for NAT. NAT allows the use of private IP ranges on a LAN (e.g.,, sharing one external Internet address and is the standard configuration in most IPv4 networks. But NAT causes problems with some applications because it requires the router to change address and port fields in the packet headers. If there is a sufficient number of globally unique Internet addresses for an organization, NAT is unnecessary, although it still can be used on IPv6.

Several tunneling protocols were developed for the times when you couldn’t necessarily assume that network connectivity supported IPv6, but these times are largely past. If your systems aren’t capable of running IPv6, they are likely so old that updating them should be a priority for many reasons beyond IPv6.


Internet Protocol Security (IPsec) is a network-layer (OSI Layer 3) protocol that allows two hosts to mutually authenticate and encrypt packet data using strong encryption. It is the dominant protocol for virtual private networks (VPNs). The original development work for IPsec was done for IPv6, but enough parties clamored for it and for the associated Internet Key Exchange (IKE) that they were back-ported to IPv4, on which they found widespread adoption.

Originally, IPsec was to be a mandatory feature of all IPv6 deployments, but the IETF decided (quite reasonably) to make it a recommendation rather than a requirement, to allow for IPv6 implementations with smaller footprints.

Header/packet format changes

The designers of IPv6 took the opportunity to simplify and rationalize the packer header format, based on lessons learned from IPv4. Many fields that are required in IPv4 are optional extensions in IPv6. The changes mean that routers have a much simpler task in the common cases.

Another major simplification for routers comes from the fact that packet fragmentation and reassembly is the job of source and destination nodes, not the routers. It is also possible, of course, that fragmentation can occur at lower levels of the protocol stack, basically Ethernet.

As described below in the security improvements section, there are other new rules about packet fragmentation meant to prevent security failures.

Improved support for extensions and options

Extensions to the IPv6 protocol (such as IPsec) can be implemented as optional headers without affecting the core packet structure. The IPv6 RFC itself defines several extensions, including:

  • The Hop-by-Hop Options header: Used to carry optional information that may be examined and processed by every node along a packet's delivery path.
  • The Routing header: Used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination.
  • The Fragment header: Used by a source to send a packet larger than would fit in the path maximum transmission unit (MTU), which is the largest packet size at the network layer.

Flow labeling capability

A source can add a 20-bit label to the headers of a series of packets it wishes the destination(s) to view as a flow, or stream, of packets, probably for some real-time or streamed application. The label acts as a hint to routers and switches to keep the packets on the same outbound path so as not to reorder them.

Security and reliability improvements

Numerous features in IPv6 improve security, or at least facilitate the improvement of security. Hosts and routers are directed to behave, or not behave, in certain ways to prevent malicious behavior. The full list is long, but here are examples:

  • Address generation: As mentioned above, the vast address space of IPv6 means that all hosts can get actual addresses on the Internet. This is a good thing in many ways, but it has led to privacy concerns. A globally unique IP address, combined with the embedded interface identifier (IID, which is generally a network card MAC address), could be used to track the movement of a specific device and user wherever they go. The solution is for the host to generate a pseudo-random IID, a large, opaque value, which the router presents to outside hosts as the IID. Both the IP address and IID can change over time without loss of connectivity for the user and device. There are several protocols for generating and managing such IIDs. IPv6 includes one, as part of Stateless Address Autoconfiguration (SLAAC), an IP address allocation system similar to DHCP (which remains available for IPv6 as DHCPv6).
  • Packet header fragmentation: Fragmented packet headers have created problems for firewalls and other network applications for a long time. A stateless firewall, presented with a fragmented packet where the chain of headers spans multiple fragments, may lack sufficient information to judge whether it should forward the packet and then either discard or forward it and the fragments that follow, possibly against policy. In fact, such fragmentation has been used in some cases to evade security controls. To prevent this, RFC 7112 requires that when a host fragments an IPv6 packet, it must include the entire IPv6 header chain in the first packet.

Isn't it time you embraced IPv6?

In recent times, many years have been declared the year of IPv6. It’s always true to an extent, because IPv6 growth has been increasing. Google keeps a public graph of the percentage of users connecting to it over IPv6—it just recently hit 25 percent, and that’s a lot.

We are at a point where you can still get away with ignoring IPv6, but we are well past the point where such behavior could be mistaken for good practice. The fact is that the public IPv4 address pool ran out many years ago and any reasonable effort to plan for the future includes an IPv6 adoption plan.

IPv6 may seem new to you, but it has been around for about 20 years and is a fully mature technology. To ignore it is to ignore the future.

This article/content was written by the individual writer identified and does not necessarily reflect the view of Hewlett Packard Enterprise Company.