Indeed it gets slightly more complicated. Floppy disks (which are about to disappear from the shelves of PC World) are customarily referred to as 1.44MB capacity. Strangely, and for reasons that are not entirely clear, this refers to 1.4 x 1000 x 1024 bytes! In the customary parlance for disk sizes, they should in fact be 1.475MB capacity!

In an attempt to reduce the confusion over the terminology here, a new naming convention has been adopted by, among others, the IEEE. The terms “Kilo”, “Mega”, “Giga” etc., are SI symbols which represent 1000, 1000,000 and 1000,000,000 etc. The multiples of 1024 are referred to by adding “Bi” (short for “Binary”) to the first two letters of the SI symbol. Thus we have kibibytes, mebibytes, gibibytes etc.

For more details, refer to this Wikipedia article.

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 Google Maps API allows the inclusion of google maps on your own pages, and you can use the Asynchronous JavasScript and XML (AJAX) to interact with the maps. It is all very interesting, and I want to do more with this – not least because of the seamless fusion between GIS data (of which I have a fair amount) and the web.

I have previously used MAPServer, but whilst google maps does not have all the feautures of MAPServer, it odes come with a complete set of maps included!

So here is the problem. At www.root-servers.org you will find a complete list of the 13 DNS root name servers that make all other name service lookups work. But where are these root name servers?

Well this is not accurate to the street level, but I used the information on the site to geocode locations for the root name servers, and you can view them at myRoot Nameservers page.

In the last few years there has been much experimentation and roll out of IPv4 Anycast Services to clone the functionality of these thirteen key root name servers. This reduces the clustering of all the vital name servers around the Washington DC area, and provides faster lookup to localities that were historically far removed from the nameservers. I again geocoded data from root-servers.org to come up with this page of the current location of all Worldwide Root Nameservers.

Let me know what you think.

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