Steve Gibson discussed IPv6 on his Security Now Podcast (number 25), and as I have said elsewhere, made a few errors, but this bit was interesting:

STEVE:  [...]  So we have, you know, 4.3 almost billion IPs currently[in the IPv4 addressing scheme]. Well, 28 bits for addressing, which is what IPv6 gives us, is really out of control.  That’s 3.4 times 10 to the 38th power.  That’s 340 billion billion billion billion IPs.  So…

LEO:  That should be enough, at least until we conquer a few more galaxies, I think.

Okay, lets look at the numbers. With an equitable distribution of IPv4 addresses (and we don’t have an equitable distribution of addresses) we would not have enough addresses for everyone on the planet. As I am not atypical in having a home network of ten or more devices, all needing an IP address, the IPv4 range starts to look very small (especially as companies such as the Ford Motor Company and General Electric each have one about .5% of the entire unicast address space assigned to them!)

So what does IPv6 give us? Steve Gibson says 28 bit addressing. From 16 bytes? How do we get that? 16 bytes = 128 bits doesn’t it? Where did the other 100 bits go?

Well actually Steve mispoke (or maybe he has been mistranscribed) because the figures he quotes next assume 128 bits of addressing. A 128 bit range allows theoretically for 2.4 x 10³⁸ addresses. Leo says this is enough until we conquer some more galaxies. Actually, this is just enough. Forever!

How do I know? Well the number of stars in the universe is currently estimated to be about 10²². That means that we have, in IPv6, a theoretical 3.8 x 10¹⁶ addresses for every star in the universe. On the very silly assumption of one inhabited planet revolving around every star in the universe, each with a population of the size of Earth, each planet in the universe could have over 6 million IP addresses for every single inhabitant!

It is enough addresses.

But actually, 128 bits are not available for unicast IP addressing in IPv6. When Steve Gibson says that 28 bits or 128 bits is what we have in IPv6, he ignores the structure of the addresses.

64 bits of every IPv6 address are reserved for the host id on a network, and the remainder are split up into different classes. The important class for IPv6 addressing as we commonly understand IP addressing are the global unicast addresses, which have a total of 61 bits available for addressing, but these bits are split into smaller blocks – 45 bits of network id aggregation and 16 bits of subnet aggregation as things currently stand.

A company can then set up multiple site subnetworks from its 16 bit allocation. Each one of these networks can have 2⁶⁴ nodes which is nearly 2 x 10⁹ on any single network.

Now assuming we could network together our nodes at a minumum distance of 1 metre apart, we could build a single network end to end, all the way from Aberystwyth to the M25.

No, not the M25 London orbital car park. The M25 star cluster in the constellation of Sagittarius, some 2000 light years away.

This would give us an end to end round trip time on the network of 4000 years (plus a few milliseconds processing latency), which is not terribly fast. Indeed we might wonder whether it would be better to have a smaller network using the IP over Avian Carriers protocol (RFC 1149 and RFC 2549)instead!

This is excellent additional reading on IPv6 beyond what I presented in today’s lecture. Much of it covers the same ground, but from a different perspective – so hopefully it will be of help to anyone feeling confused.

I don’t want to criticise what Gibson is trying to do on this podcast. The area of security issues on the Internet is huge, and the breadth of reading he must undertake to understand the issues must not be underestimated. He is bound to make mistakes.

But on IPv6 Gibson’s is frankly wrong. He says:

If it weren’t for NAT router technology that basically allows many machines to share a single public IP, we really would be in trouble already with IP space depletion. But NAT routers happened, and they’re just a good thing for everybody. Corporations are using them. There are even some ISPs that are using NAT routers and putting all their customers behind a big NAT router because it really works very well, not perfectly, but very well, as most home users know. And so the prevalence and birth of NAT routing technology has hugely reduced the pressure on the move to IPv6.

Steve Gibson is wrong as follows:

• NAT is not a good security solution. The part of NAT that is adding security is the same part that adds security in a non NAT perimeter firewall.
• The gains from NAT have largely been achieved with respect to address depletion. NAT extended IPv4 to give us time to migrate to IPv6, but the gains are not limitless. See the posts on this blog about IPv4 address depletion – we have only about four years of IPv4 addresses left by current best estimates.
• NAT actually doesn’t work that well. We are just getting good at working around its limitations. This is why Gibson endlessly pushes the proprietry non-standard Hamachi solution for encrypted tunnels, and other mechanisms to make some kind of peer to peer work on the Internet.

IPv6 has so much more to offer than Steve Gibson realises. Zero configuration, IP mobility, multiple addresses per interface, router discovery, link level encryption (he mentioned that one in passing), authentication… the list goes on.

He also says:

The problem is that it’s not easily compatible with IPv4. The problem that IPv6 is having is, you know, the manufacturers who are making the routers, I mean even, for example, the PC manufacturers are supporting Version 6, though no one’s using it yet. You know, Windows Server 2003 and XP can do IPv6. But you can’t get it anywhere. I mean, there’s nowhere to plug it in to get Version 6

Actually IPv6 does play very nicely with IPv4, and you can get it now. See for instance the BT Exact tunnel broker service. Some ISPs are now starting to offer IPv6 to their customers.

The real worry here is that Gibson clearly does not understand the mechanism by which we must transition from IPv4 to IPv6. There is not going to be a single big switch over. We must create islands of IPv6 (falling back on IPv4 automatically when we must). We connect these islands by one of the many tunnelling protocols, and as the islands grow, the sea of IPv4 is slowly pushed back. Before you know it we are all using IPv6 – just in time to stave off address depletion.

There is some good stuff in the Security Now podcast, but Steve Gibson saying IPv6 will never happen is not an example of it.

This article takes you through the basics of IP addressing and provides an easy strategy for working with those numbers for calculating an appropriate subnetting strategy. It has a heading “The Hardest Subnetting Problem” which looks much like an examination past question (only harder!), and a fully worked example. It also speaks briefly about working with IPv6 addresses in the summary.

Well worth a read.

The Internet Protocol Journal

Geoff Huston’s dynamically generated graphs

Tony Hain’s latest quaterly updates

The .cym Campaign

Ping Wales article on the .cym campaign

The .cw Campaign


  W 5224.771484
  N 404.355896


The sharp eyed reader will realise that actually, latitudes are a number of degrees north or south of the equator, whereas longitudes are a number of degrees east or west of the prime meridian (in Greenwich… did I mention I recently got lost on my way home from Greenwich?)

Even sharper eyed readers will realise that Aberystwyth is roughly 4 degrees to the west of Greenwich and roughly 52 degrees north of the equator. So what is happening here?

I think it is a Mac stumbler bug. I haven’t checked, but essentially I just ignored the letters “N” and “W” when converting my data in my XSL stylesheets in the previous post. If you are east of Greenwich or south of the equator, you will have to fix the stylesheets by hand!

The forward of the article reads:

Over the past decade numerous IP-related technologies have generated some level of technical controversy. One of these is the Network Address Translator, or NAT. This article describes the inner workings of NATs in some detail, and then looks at the issues that have accompanied the deployment of NATs in the Internet that appear to have fueled this technical controversy. NATs are a very widespread feature of today’s Internet, and this article attempts to provide some insight as to how they operate, why there is such a level of technical controversy about NATs, and perhaps some pointers to what we have learned about technology and the process of standardization of technology along the way.

The answer is that the default window size is just 16KB. The value can be adjusted in the registry, and the details are listed below. The TCP1323 key will turn on the window scaling option. The second key raises the default window size from 16KB to 128KB, and the third option sets the maximum window size for all connections to 1MB (if you don’t set this, the default in Windows is 64K, and this will take precedence over your other parameters).

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323=1
HKLM\SYSTEM\CurrentControlSet\
      Services\Tcpip\Parameters\TcpWindowSize=131400
HKLM\SYSTEM\CurrentControlSet\
      Services\Tcpip\Parameters\GlobalMaxTcpWindowSize=1048576


The global max tcp window size parameter illustrates something I did not mention in the lecture – that during the lifecycle of a connection, TCP implementations can adjust their buffer sizes on the fly. Adjusting downwards can be problematic (leading to shrinking windows), but adjusting upwards allows the operating system to allocate more memory only to those TCP connections that require large buffers.

On Linux you can achieve the same thing. To change TCP settingson 2.4 kernels and later, you add the entries below to the file /etc/sysctl.conf, and run “sysctl -p”.


# increase TCP maximum buffer size
net.core.rmem_max = 1048576
net.core.wmem_max = 1048576
# increase Linux autotuning TCP buffer limits (min, default max)
net.ipv4.tcp_rmem = 4096 131400 1048576
net.ipv4.tcp_wmem = 4096 131400 1048576


On a Mac, the same effect is obtained with these commands:


sysctl -w kern.ipc.maxsockbuf=1048576
sysctl -w net.inet.tcp.sendspace=131400
sysctl -w net.inet.tcp.recvspace=131400


Apple also provides a Broadband Tuner patch that does some similar tuning for you on Mac OS X 10.4 and above.

The Mac is based on BSD, and the method for tuning BSD is similar. Add the following lines to /etc/sysctl.conf and reboot.


kern.ipc.maxsockbuf=1048576
net.inet.tcp.rfc1323=1
net.inet.tcp.sendspace=131400
net.inet.tcp.recvspace=131400


Obviously the actual values you use for buffer sizes will depend on the bandwidth and latency of your networks, but these values above should be a good starting point.

1) Take a look at the website for Behrouz Forouzan’s “TCP/IP Protocol Suite” (the course text). There are some powerpoint slides for chapter 5 (the chapter on subnetting) that go into considerable detail about subnetting and CIDR.

2) Wikipedia has an entry that (at the moment at least) is substantially complete.

3) Tech Republic has an IP subnetting made easy article, which claims to provide a clear and graphical method of understanding subnets. I am not sure if I agree that this site is particularly clear, but on the basis that different people learn differently, I offer it up. Please comment to let me know if it helps or not.