Differences Between IPv4 and IPv6

Although IPv6 was based heavily on IPv4, there are a number of significant differences between the two standards.

Address Length

The most obvious difference is the increase in length of addresses, from 32 bits in IPv4 to 128 bits in IPv6. This increases the total address space size from 232 (about 4.3 billion) to 2128 (about 340 trillion, trillion, trillion). It also doubles the size of the Packet Header, which adds 20 bytes of additional overhead on every packet.

IP Address Representation

The next most obvious difference is IPv6’s use of “coloned-hex” (e.g. 2001:470:20::2) for external data representation, instead of IPv4’s “dotted-decimal” (e.g.

Both IPv4 and IPv6 addresses are represented internally (in memory, or on the wire) as strings of bits (32 of them for IPv4, 128 of them for IPv6).

IPv4 addresses are represented externally with 4 fields of 8 bits each, using up to 3 decimal digits in each field (values 0 to 255). Fields are separated by dots (“.”). Leading zeros can be suppressed in each field.

IPv6 addresses are represented externally with up to 8 fields of 16 bits each, using up to 4 hexadecimal digits in each field (values 0 to ffff). Fields are separated by colons (“:”). Leading zeros can be suppressed in each field. At most one string of all-zero fields can be replaced by “::”. In effect, everything to the left of the “::” is left justified in the 128 bits, everything to the right of it is right justified in the 128 bits. The extreme cases of this notation are the “unspecified address” (128 bits of 0), represented by “::”, and the loopback address (127 bits of 0 followed by a single 1 bit), represented by “::1”.

Packet Header

Packet Headers are affixed to the beginning of all IP packets. You can think of them as being like “shipping labels” pasted on a package. A Packet Header contains a “from” address (where the packet is being sent from) called the source address; and a “to” address (where the packet is going) called the destination address. In the case of packets, these addresses are not “street” addresses, but IP addresses. On IPv4 packets, there is an IPv4 Packet Header. On IPv6 packets, there is an IPv6 Packet Header. These have the same purpose, but are fairly different due to improvements in the IPv6 protocol.

The IPv4 Packet Header is 20 bytes long (plus the length of the options field, if any). All but one bit of the first 20 bytes has long since been accounted for. There is no official Header Extension mechanism (although IPsec uses something similar). Some fields are used only in fragmented packets, but take up room on all packets.

ipv4 packet header

The IPv6 Packet Header is actually simpler than the IPv4 Packet Header, because some fields were eliminated, and others moved to Extension Headers. It is twice as large (40 bytes) due to the gigantic (128-bit) source and destination IPv6 addresses (four times the size of IPv4 addresses). Every bit of the basic IPv6 Packet Header has been accounted for, but it is possible to add any number of new Extension Headers, which didn’t exist in IPv4, so this is not a problem.

ipv6 packet header

The changes from IPv4 Packet Header to IPv6 Packet Header are as follows:

IPv4 Version field – same size (4 bits), same name, same function, in IPv6 Packet Header.

IPv4 IHL (Internet Header Length) field – discarded since IPv6 Packet Header is fixed length (40 bytes).

IPv4 Type of Service field – same size (8 bits), new name (Traffic Class), same function in IPv6 Packet Header.

IPv4 Total Length field – same size (16 bits), new name (Payload Length), now does not include length of the Packet Header, so new Payload Length = old Total Length – 40.

IPv4 Identification (Fragment ID) field – twice as big (32 bits), same name, same function, moved to Fragmentation Extension Header.

IPv4 DF flag – discarded, effectively always 1 (set) in IPv6.

IPv4 MF flag -same size (1 bit), same name, same function, moved to Fragmentation Extension Header.

IPv4 Fragment Offset field – same size (13 bits), same name, same function, moved to Fragmentation Extension Header.

IPv4 Time-To-Live (TTL) field – same size (8 bits), new name (Hop Limit), same function in IPv6 Packet Header.

IPv4 Protocol field – same size (8 bits), new name (Next Header), same function, in IPv6 Packet Header. There is a new set of possible values (some are the same as in the Protocol field in the IPv4 Packet Header, such as values for TCP, UDP and SCTP).

IPv4 Header Checksum field – discarded, considered to be superfluous.

IPv4 Source Address field – new size (128 bits instead of 32), same name, same function, in IPv6 Packet Header.

IPv4 Destination Address field – new size (128 bits instead of 32), same name, same function, in IPv6 Packet Header.

IPv4 Options field – discarded (virtually never used in IPv4 Packet Header) – now Packet Header is fixed length (40 bytes) instead of 20 bytes + length of options field.

Note: the order of the fields was also moved around some from the IPv4 Packet Header, to make fields line up better on 32 bit boundaries.

NAT and Private Internets

Since there is no shortage of IPv6 global addresses, there is no need whatsoever for NAT66 (NAT from IPv6 to IPv6). This means we can restore the original (pre-NAT) End-to-End global connectivity. Any node on the entire IPv6 public Internet can in theory connect directly to any other node on the entire IPv6 public Internet (unless blocked by firewall rule or router ACL anywhere along the way). Deploying firewalls is actually much simpler and more likely to be done correctly in IPv6 because NAT is not in the way (no need for “proxy addresses” or “proxy ARPs”, like with IPv4 BINAT).

While you can still deploy private internets with IPv6, there is no need to do so just because there aren’t enough IPv6 addresses. You could deploy them using Unique Local Addresses. You could link several disjoint parts of your private internet together with VPN links over the public Internet if needed.

There is no exact equivalent to IPv4’s RFC 1918 “addresses for private internets” as widely used in IPv4 networks today. The original “site local addresses” (fec0::/7) were similar in nature, but were deprecated by RFC 3879, “Deprecating Site Local Addresses”, September 2004. They were replaced with Unique Local Addresses (ULAs), in RFC 4193, “Unique Local IPv6 Unicast Addresses”, October 2005.

ULAs have some very real uses, but since there is no “global IPv6 to ULA” NAT, they do not work like RFC 1918 private addresses, nor would you want them to work that way. If they did, we would be right back with zillions of private internets that have one-way connectivity to the IPv6 Internet. When everyone can have as many IPv6 global addresses as they can conceivably use, there is no need to do this.

Address Resolution

IP “address resolution” involves mapping Internet Layer addresses (IP addresses) to Link Layer addresses (e.g. MAC addresses). This must be done to get packets to the desired node over Ethernet.

IPv4 uses ARP, specified in RFC 826, “An Ethernet Address Resolution Protocol”, November 1982. This protocol lives in the Link Layer. There is no way to secure it, so it is a favorite target of hackers, and there are many potent hacking attacks against it.

IPv6 uses Neighbor Discovery Address Resolution to map an IPv6 addresses onto a MAC address (or any Link Layer Address). This protocol lives in the Internet Layer, and you can protect it with IPsec AH and/or ESP if you desire (tunnel mode or transport mode). There is a secure version of Neighbor Discovery that provides an even better way to secure Address Resolution. This is specified in RFC 3971, “SEcure Neighbor Discovery (SEND)”, March 2005. Unfortunately, Microsoft has not implemented this in any version of Windows, so it is not really usable in most networks. It is supported in both FreeBSD and Linux. SEND is fairly complicated to deploy, as it needs a working PKI (or equivalent) to create the necessary digital certificates.

Transmission Modes

IPv4 Supports unicast (one-to-one), multicast (one-to-many subscribed), and broadcast (one-to-all) transmission modes. There are four IPv4 unicast scopes: node-local (loopback,, link-local (APIPA,, site-local (RFC 1918 private addresses) and global (all other IPv4 addresses not otherwise reserved).

IPv6 supports unicast (one-to-one), multicast (one-to-many subscribed) and anycast (one-to-closest-of-many) transmission modes. There is no broadcast mode in IPv6. There are four scopes for unicast addresses: interface-local (loopback), link-local (fe80::/64), site-local (ULA, fc00::/7) and global (2000::/3). The original site-local (fec0::/64) was deprecated.

Multicast Addresses

IPv4 uses “Class D” addresses ( to for multicast. This is a total of 268 million multicast addresses. Support for multicast is optional in IPv4 routers, so many do not support it. It usually works only within “walled gardens” where one entity owns and manages all of the routers.

IPv6 has strong support for multicast in all scopes. It uses the block ff00::/8. There are 2112 possible IPv6 multicast “groups”. This is a total of 5.19E+33 multicast addresses. There are six multicast scopes: interface-local (loopback), link-localsite-localadmin-localorganization-local and global. Multicast is used extensively in IPv6 mechanisms, such as Router Discovery and Stateless Address Autoconfiguration, so support is mandatory. The Multicast Listener Discovery Protocol (MLDv1 and MLDv2) are actually subsets of the ICMPv6 protocol. IPv6 multicast scales very well, potentially to the entire world.


IPsec is short for Internet Protocol Security. It was originally created as a part of IPv6, but has been retrofitted (badly) into IPv4. It works OK in a private internet with no NAT, but it does not cross NAT very well. It uses something like a digital signature to detect changes to IP addresses or ports (in the header), which is exactly what NAT does. So, IPsec correctly identifies NAT as an attack. It is possible to use NAT traversal, such as STUN, to make IPsec work even through NAT, but that introduces more problems than IPsec solves in the first place. Because of this, IPsec is not widely used in IPv4.

IPsec works great in IPv6 because there is no NAT to break it.

IP Subnetting and CIDR

Because of the scarcity of IPv4 addresses, IPv4 had to use variable length masks and CIDR. This means that the split between the address prefix (or “network address”) and the address suffix (or “interface identifier”) can come at any point in the 32 bits (from bit 8 down to bit 30). This makes subnetting very complex in IPv4.

There is no scarcity of IPv6 addresses. Virtually all IPv6 subnets split the address prefix and address suffix at bit 64 (64 bit prefix and 64 bit suffix, or interface identifier). There is no subnetting required in the bottom 64 bits. There are some subnetting issues with managing the Subnet IDs if your IPv6 allocation is greater than one /64 block (e.g. a typical company allocation of a /48).

ISP Address Allocation

Because of the scarcity of IPv4 addresses, it is difficult and expensive to get many IPv4 public addresses with ISP service. A home user typically gets only one public IPv4 address. An organization may get from 5 usable (a /29) to 253 usable (a /24) public IPv4 addresses with a commercial account, depending on cost and availability. Recently, ISPs have been deploying Carrier Grade NAT, or CGN (see RFC 6598, “IANA-Reserved IPv4 prefix for Shared Address Space”, April 2012. With this, customers don’t even get a single public IPv4 address. They get one (or a few) RFC 1918 private addresses, which they must then do another layer of NAT behind (so there are two layers of NAT between the end-users and the IPv4 Internet). This causes many problems.

There is no scarcity of IPv6 addresses. Customers can have more than enough to assign one or more public addresses to every node they have.

A home user gets at least one /64. In some cases the may get multiple /64s, perhaps a /60 (sixteen /64s). Each /64 is good for one subnet, and is 4 billion times as many addresses as in the entire IPv4 address space.

Even a small organization should get at least a /48 block, which is 65,536 /64 blocks (each sufficient for one subnet). There are enough /48 blocks in the 2000::/3 block marked for allocation to give every human alive today over 5,000 of them.

Network Auto-Configuration

In IPv4, network auto-configuration is typically done with DHCPv4. This uses broadcast for discovery of the DHCPv4 server (or relay agent), and to receive the reply from the DHCPv4 server (or relay agent). DHCPv4 provides stateless information that is the same for every node in the subnet, for things like subnet mask, default gateway, and IPv4 addresses of DNS. It uses stateful allocation to provide a unique node address to each node, on a lease basis. There is no security in DHCPv4, and it is simple for a hacker to do denial of service, or broadcast bogus address information to nodes with a rogue DHCPv4 server. It is possible to create address reservations, so that nodes that require a stable address will get the same address every time.

Every IPv6 compliant node will autonomously generate a link-unique Link-Local unicast address whether or not there is a source of Router Advertisement messages present.

In IPv6, network auto-configuration can be done with only Stateless Address Autoconfiguration (SLAAC), one of the mechanisms of Neighbor Discovery. This will automatically determine the default gateway address, and autonomously generate one or two global unicast IPv6 addresses for each prefix found in Router Advertisement messages. A recent standard, RFC 6106, “IPv6 Router Advertisement Options for DNS Configuration”, November 2010, provides a way for routers to include the IPv6 addresses of DNS (and a DNS search string) in Router Advertisement messages. This is implemented in FreeBSD and Linux, but is not currently implemented in any version of Windows. Without this option, there is no way for nodes to automatically learn the IPv6 addresses of DNS if only SLAAC is used.

Auto-configuration can also be partly done with only DHCPv6, by disabling SLAAC and enabling the “Managed Address” option in your OS. Unfortunately, when you disable SLAAC, the nodes cannot automatically determine the default gateway, so that must be manually configured. It would be simple to add a default gateway option to DHCPv6, but for some reason, the people in charge of DHCPv6 are opposed to that idea.

Auto-configuration is typically done with a combination of SLAAC and DHCPv6. The default gateway and one or two autonomously generated global unicast addresses are obtained via SLAAC. If the Router Advertisement message indicates that there is any DHCPv6 server available (stateless or stateful), the node will obtain IPv6 addresses of DNS from it (the node will locate the DHCPv6 server by using a special link-local multicast address). If the received Router Advertisement message indicates that there is a stateful DHCPv6 server available (M flag = 1), then the node will obtain yet another IPv6 global unicast address from DHCPv6. It is possible to create address reservations as with DHCPv6 (similar to with DHCPv4), so that a node that requires a stable address will always obtain the same global unicast address from a stateful DHCPv6 server. Using SLAAC and DHCPv6 together results in each node having multiple global unicast addresses, most of which are effectively randomly distributed in the /64 block (only the address obtained from a stateful DHCPv6 address via an address reservation can be centrally managed). This approach makes management of firewall or Network Access Controls (not to mention restricted access by IP address to services) very difficult or impossible.

Minimum MTU

In IPv4 the minimum MTU is 586 bytes. Every IPv4 link should be able to handle 586 byte packets (most will handle much larger packets). In IPv6 the minumum MTU is 1280 bytes. Every IPv6 link should be able to handle 1280 byte packets (most will handle larger packets). A dual stack link should be able to handle the larger of these, or 1280 bytes.