IPv6: Part 1 – I could see you all ignore the fact we’d fill up IPv4

After several friends asked about it, and because of the recent featured article on the BBC technology news site, I thought I would do a series on IPv6. I consider myself somewhat of an authority, because my honours project, dissertation and paper were on IPv6 – the actual title being IPv6, its implementation and migrating from IPv4 – I had what I thought were better ideas for a project but I figured IPv6 knowledge would increase my employability in the coming years.

The series starts with theory and need, then a few posts on local implementation, a couple of scenarios for wider implementation, then a final article on the reticence of the IT world to IPv6 and what I think is causing it.

So starting with theory and the need for IPv6, I know they’re not glamorous, I know to some they may be mind numbing and they’d rather just get on and do it, the whole don’t talk or discuss just do mentality. I can sympathise with this opinion. That being said, sorry no dice, you need a good mix of practical and theory otherwise you get into the area of call cargo cult system administration – I’ll probably discuss that phrase more in a future post – where you follow something like a ritual with no actual understanding.

Why do we need IPv6?

The Internet currently runs on IPv4 whose addresses are 32 bits long, with an address space of 232 resulting in 4,294,967,296 or about 4.3 billion addresses. This was considered a suitably large number when IPv4 was created, but its running out, estimates vary from the conservative one year to the liberal five years – which assumes a lot of tinkering by the IANA, such tinkering would be prohibitively expensive in places and by no means certain – It doesn’t really matter which one is right, in the long run IPv4 is running out of addresses.

IPv6 addresses are 128 bits long with an address space of 2128 resulting in 340,282,366,920,938,463,463,374,607,431,768,211,456 – having trouble saying that, well it’s 340-undecillion, 282-decillion, 366-nonillion, 920-octillion, 938-septillion, 463-sextillion, 463-quintillion, 374-quadrillion, 607-trillion, 431-billion, 768-million, 211-thousand, 456 or about 340 trillion, trillion, trillion addresses. This is currently considered a suitably large number with a high degree of future proofing. To give it some scale:

  • Its enough addresses for many trillions of them to be assigned to every person on the planet. Assuming the earth has 6.5 billion people, each person could be assigned 295 or 3,961,481,257,132,168,796,771,975,168 addresses
  • The Earth is about 4.5 billion years old. If we had been assigning IPv6 addresses at a rate of 1 billion per second since then, we would have by now only used up less than one trillionth of the address space.

For a more extensive and always up-to-date report on the exhaustion I’d recommend Potaroo (it also has a nice countdown widget).

You’re wrong, NAT and CIDR will save me?

No they won’t. The IT community saw this exhaustion coming in the early nineties, at the time they created NAT and CIDR to delay it while they worked on IPv6. NAT and CIDR have bought us about twenty years, we can’t really expect much more from them. I realise some of the imaginary people reading this may be insulted by my assumption in asking this question, I make it because one fairly senior internal IT guy from Abertay (my former university) who talked to me during the end of year open day, tried to lecture me on how my project was crap because of NAT, after face-palming I proceeded to rip his argument apart. Since then though a friend from Dundee College IT support has conveyed similar opinions. I’m guessing that’s the preferred opinion of the alpha-geek in the area. I know it’s not a JANET member opinion, so I’m guessing it’s just Dundee College and Abertay University or perhaps the prevailing opinion of FaTMAN (Fife and Tayside Metropolitan Area Network).

The problem, the reason for this opinion is a lot of educational establishments still use public routable IPv4 addresses for clients, so they think they can just switch to NAT, sell on the addresses and that’ll be that. They fail to realise the scale of exhaustion, lets say they moved to NAT and it freed about two to ten thousand addresses per campus, that’s not going to make much of a difference; its negligible with current demand and that assumes no growth, also renumbering those addresses may not be practical or cost effective. I’ll probably cover this aversion to IPv6 in more details for the last article.

Wait what about IPv5?

There was an IPv5, also called the Internet Stream Protocol or ST. It was created in the late 1970s, IPv5 was designed to deal with streaming media Рsending video, audio, and simulations over the Internet РIt used IPv4 addressing, its main advantage over IPv4 UDP for media was that it offered connections and guaranteed QoS. For a while it gained a small following in places like IBM, Apple and Sun, they even revised it into ST+/ST2/ST2+. IPv5 was never accepted as a standard, the work done on it was not lost however, much of its concepts were implemented in MPLS. And That is why the next generation internet protocol is called IPv6 and not IPv5.

IPv6 addresses are too complicated?

IPv6 addresses are too complicated, the average user has trouble with IPv4, I mean 2001:41c8:0001:5a19:0000:0000:0000:0002 who’s going to remember that.

When I was first made aware of IPv6 I thought this also, since then after looking at it more closely, I’ve changed my mind. Lets explain the address hierarchy then break down that example address.

All IPv6 addresses consist of 8, 16 bit HEX blocks, separated by colons – this is known
as colon hexadecimal notation – as illustrated in the above example. IPv6 uses an address hierarchy – which incidentally also helps with routing – that looks like this:

[bash light=”true”] Internet backbone -> ISP -> Organisation (building or individual connection) -> Subnets -> Hosts[/bash]

32 bits are assigned to each ISP from the Internet backbone and from this the ISP allocates 48 bit addresses to organisations. 48 bits are assigned to the organisation – combining the 32 bits from the ISP plus 16 bits for the organisation – and are globally unique, this is not assigned to the organisations entire global presence but rather to each site; to each external connection to the internet, so each will receive its own /48 address. 16 bits can then be used for organisational subnetting this gives us 65535 potential subnets. Leaving 64 bits to define unique hosts per subnet, giving us a potential 18,446,744,073,709,551,616 or eighteen quintillion, four-hundred-forty-six quadrillion, seven-hundred-forty-four trillion, seventy-three billion, seven-hundred-nine million, five-hundred-fifty-one thousand, six hundred and sixteen per each of the 65535 subnets. That last portion, which is just being assigned to hosts is twice the bit length of the entire IPv4 address pool. So a 128 bit IPv6 address can be viewed as two 64 bit addresses. The 64 bit address to the left defines the globally unique prefix or the 48 bits assigned by ISP and the 16 bits used for subnetting. The remaining 64 bits to the right are assigned to the host interface on an appropriate subnet.

Taking this back to the 2001:41c8:0001:5a19:0000:0000:0000:0002 example:

  • 2001:41c8 = 32-bits, which denotes the ISP.
  • 2001:41c8:0001 = 48 bits (ISP + 16 bits) which are globally unique and assigned by the ISP from its /32 address.
  • 5a19 = 16 bits to be used for subnetting purposes.
  • 0000:0000:0000:0002 = 64 bits to be used to identify the host or network interface.

There are perhaps some security or privacy concerns about hierarchical addressing but I’ll discuss them later.

Moving on to address complexity, in IPv6 addresses contiguous blocks of 16 bit zeros can be replaced with :: only one set of :: may be used per IPv6 address to avoid expansion confusion, leading zeros may be dropped. Notation may combine :: and dropped leading zeros to form a compressed IPv6 address, the following are all the same address and all considered valid:

  • 2001:41c8:0001:5a19:0000:0000:0000:0002
  • 2001:41c8:0001:5a19:0:0:0:2
  • 2001:41c8:1:5a19::2

I’ll admit the addresses could still get complicated in certain situations, I think we need to move towards properly implemented DNS to solve this problem, but I have an unhealthy love and fascination for DNS so I would say that.

So what are the features of IPv6

IPv6 has a lot of features and improvements over IPv4 and while I won’t enumerate them all here, a few notable examples are listed below.

IPv6 has a new header format which is fixed length, this improves performance, lessens fragmentation and when combined with the use of link-local addresses offloads a lot of work from the router and networking layer to the protocol and transport layer.

IPv6 allows two types of configuration:

Stateless – this is like a better version of the current APIPA 169.254.x.x addresses. With this method the host configures itself via multicast without a DHCPv6 server and/or router.

Stateful – which is where the host configures itself with information provided from DHCPv6 server and/or router.

True automatic configuration is now possible, a link-local address is auto-configured for each IPv6 connected host. Each host will perform router solicitation via ICMPv6 router discovery messages, that is, it will search its default subnet for a router, which it will communicate with in order to gain further insight into the network and how it should configure itself. In addition IPv6 hosts can perform DHCPv6 solicitation, though DHCP is all but obviated in IPv6 networks not requiring advanced DHCP options. Router solicitation is preferable and has priority, both may be used in conjunction if certain DHCP specific configuration options are required. Generally routers pass along prefixes to be autoconfigured on IPv6 hosts and DHCPv6 servers pass along prefixes and/or additional settings, such as where to find NTP or WINS servers.

IPv6 supports three types of addresses:

A unicast address – unique address for a device (host/router/phone/etc).

A multicast address – groups common systems (routers/hosts/etc).

An anycast address – represents the closest address, used heavily in multihomed environments, so if a server had three interface cards on different subnets and was providing the same service to each subnet an anycast address would represent the closest address to your subnet to contact that service. These address types lower overhead and increase network performance.

IPv6 hosts uses Neighbour Discovery (ND) over multicast to find hosts, ND replaces ARP and other broadcast-based techniques and lowers network overhead.

IPv6 obviates the need for NAT because all hosts/devices, including mobile devices are assigned a Globally Unique ID (GUID) based on the prefix assigned to your service provider. Devices are still secure with the use of a firewall or properly configured network, they just now have the potential of being public routable.

The minimum MTU is 1280-bytes compared to 576-bytes for IPv4, this means larger packets can be sent assuming bandwidth is available. IPv6 supports JumboGrams – packets larger than 64k; each IPv4 packet could only have a payload of up to 64 KB, while each IPv6 packet can have a payload of up to 4GB. While such large packets are unlikely to be a regular occurrence they have uses in high-MTU networks, such as upstream or back-end providers


Okay we’re done here, if you have any questions on the theory or need, post a comment. Beyond that be on the look out for part 2.