Y Safle

The media is working itself up into a feeding frenzy again. This week’s issue: the alleged dangers of WiFi radiation. First BBC Radio news, then Newsnight, now the Daily Telegraph have all had articles from quoting from people who believe that there might be health risks from WiFi. The BBC programmes at least balanced the sillier claims by noting that WiFi power output is far lower than that from mobile phones.

The Daily Telegraph, on the other hand, had this nonsense:

However it is believed that a classroom containing 20 laptops and two routers could combine and be equivalent to the emission from a mobile phone.

Notice the use of passive voice: “it is believed”. Who believes this?

It turns out that no-one does, although the Telegraph quotes from the “Powerwatch” web site. On this site, there is a calculation designed to show that a room full of 20 computers and an access point (or two) is approaching the power output of a mobile phone call.

But this is arrant nonsense. It is nonsense because of the silly assumptions being made about average distance from antennae. It is nonsense because they first make an assumption of low power output from the phone, and it is especially nonsense because it makes no difference whether you have one computer or fifty in a room. The maximum power output is the same - capped in the UK at 100mw (but usually less than this).

Let me explain: WiFi stations are receiving a radio signal when they receive data. But if two stations transmit a signal at the same time then what occurs is a collision - the signal is garbled and not received. The solution is that WiFi uses a collision avoidance scheme to try to ensure that packets are never sent out whilst another station is already transmitting. A couple of carrier sense mechanisms are used to do this, and the result is a very low collision rate. Essentially, if one station is talking, all the other stations are quiet. Click on the thumbnail image to see how this looks in practice. Each wireless station waits a random amount of time before transmitting, and if another station transmits first, the wireless station will quietly defer to it.

Therefore the maximum power output from a room of 20 computers remains capped at 100mw. What is more, no one station is transmitting all the time. For the majority of the time, even on a congested network, each station is actually transmitting nothing.

And that brings us to the next bit of nonsense - the assumption of the amount of traffic in transit. The powerwatch page assumes more than 100% usage for periods of two hours or more in its calculations. Note that if a single wireless station on an IEEE 802.11g network were downloading constantly (and that the downstream network could maintain the same throughput), then even assuming protocol overheads reduce the actual throughput to a mere 30 Mbps, over a course of two hours, that station would download some 26 Gigabytes of data.

To put this in perspective, fairly heavy Internet users download about this quantity of data in a month. Light users (people just browsing the web, using email and similar) would not get close to this figure.

26 Gigabytes is the equivalent of about 44 CD images, or several thousand podcasts. It is a guge quantity of data - not the kind of thing people will be downloading in one sitting - and certainly not regularly.

Ah, you say - but spread between 20 computers? What classroom environment is encouraging pupils to download over a gigabyte of data per computer? None!

So the assumption of 100% utilisation is nonsense.

Next problem: The assumption is made that people are - on average - a metre from the transmitting antenna.

This is just silly. The writers seem to know that magnetic fields decrease by the square of the distance from the antenna, but they assume that on average, people are a metre from the emitted radiation. Based on the fact this is a classroom, and 20 stations are variously transmitting, the fact that some of these transmitters will be many metres away only really makes this assumption if the pupils have swallowed the transmitter.

Admittedly, I wouldn’t put this past some children - but if they have done so, they probably have worse problems to deal with than the emitted signal from the station!

No, in fact the vast majority of the transmissions come from the access point. (Remember, we download much morethan we upload) this may not even be in the class, but if it is, it will probably be several metres from even the nearest child. The law of squares tells us that these signals will be far lower than the silly assumption made on the powerwatch page and repeated uncritically by the Daily Telegraph.

As one commentator on the Telegraph page says:

“Can there ever be a better example of why the current decline of Physics teaching in schools and universities is so worrying?”

Let’s give the last word to Mike Clark, senior spokesperson for the Health Protection Agency. He has run the figures rather more intelligently than the Powerwatch pressure group, and tells us that 1 year of exposure to WiFi radiation in a classroom is equivalent to 20 minutes on a mobile phone.

Maybe we could quibble and bring that down to a month or so. So what? The worry with mobile phones is that the radiation causes excitation of water molecules in the brain near where the phone is held to the head. This causes a slight warming effect which could theoretically be a cause for concern, although there is no proof of harmful effects.

WiFi radiation - if it causes any warming at all - is so slight as to be unmeasurable.

There is no risk here.

The Western Mail recently reported in slightly hysterical tone that wireless computer networks should be banned from the nation’s classrooms because of fears about their effects on health.

MP Urges Ban in WiFi Technology in Schools

Why should we ban WiFi in schools? The reasons we are being given are that parents are concerned; that we don’t know the effects of WiFi microwave radiation yet; that one teacher claimed to be getting ill whenever teaching in front of a transmitter; and that we should apply the precautionary principle.

The result? Ysgol Pantycelyn in Carmarthern switched off its WiFi network (despite the benefits these networks bring to teaching). A few other schools in England have similarly shut down their wireless networks.

Now all of the reasons above suffer from a failure to consider the scientific basis for the claims being made. They show our penchant for listening to anecdotal evidence and rating it much more highly than scientific evidence. This is a dangerous error in our thinking. We are geared up to accept personal testimony, even though such testimony is necessarily limited and often flawed.

Who can argue that there is a problem if a teacher is feeling ill when teaching in front of WiFi equipment?

Except it turns out that in a controlled experiment when the access point was sometimes off and sometimes on, but the teacher in question did not know when it was off, he continued to claim to be feeling ill when he believed (wrongly) that the access point was on.

But that spoiler won’t be widely reported. No studies have indicated that people can detect WiFi radiation.

Someone will reply that the wavelength of WiFi radiation is in the microwave band is it not? So much so that microwave ovens are one of the largest sources of interference to WiFi equipment. So aren’t we cooking people by emitting this radiation?

Look - there is a clue here in the word “interference” above. If Microwave ovens are causing interference then they have been emitting some microwave radiation (more than from access points) for many years. Have we banned microwave ovens yet?

No, because the levels of emissions are essentially harmless.

How do we know?

Because we are surrounded by microwave radiation wherever we go. I suppose we could go and live at the bottom of a deep shaft mine to avoid it. But then we would probably die of vitamin D deficiency instead.

For people living on the surface of the Earth, we are constantly bombarded by radiation at every wavelength (including plenty of microwave background radiation).

And here is the important point. In the UK at least, WiFi radiation is strictly limited to 100mw (the limit is higher in the US). That limit has a very specific purpose. It means that unless you pretty much swallow the WiFi antenna, you are not going to absorb any more radiation from the WiFi network than from the background radiation.

What is more, the signal itself is deliberately encoded to look just like background radiation. The signal is spread over several wavebands to keep the power down, and “chipped” so that it looks just like microwave “static” unless you know what to look for and how to decode it.

And the power is kept so low so that multiple users of the same wave bands can coexist. Unlike mobile phones, for instance, which use much higher powers because the cell network has exclusive use of the waveband, and does not want to put base stations every 100 metres!

So there is no scientific reason at all to suspect WiFi networks. This is the advice given by government agencies and many local authorities (although some wash their hands of the affair with useless “advice” that it is “up to the individual schools”). We don’t need to worry about the safety of WiFi networks.

But all people hear is the anecdotal story (without refutation), and the words “radiation” and “developing children”, and it won’t be long before we see a wrong headed national campaign by some newspaper to ban this dangerous hazard in our schools.

IPv4 may be nearing the end of its life, but there are still many times when network administrators need to sit down with pen and paper and calculate a subnetting scheme for a range of IP addresses.

Well the net is littered with subnet calculators that will work out subnets and supernets for you. I have added one to my site (an open source subnet calculator), which has the advantage of showing the binary masks. Nothing particularly original, but feel free to have a play.

Note that it makes an error on /31s. These are a special case used for point to point links, and a /31 has no broadcast address or network address. Thus there are precisely two IP numbers for host addressing on a /31. Very useful for point to point links (and making /30s redundant)

As the code is open source, I will probably fix it at some point… but not just yet

Enjoy.

In case you were wondering how the Internet works, US Senator Ted Stevens, representing Alaska and legislating to destroy the Internet experience for Americans, gave us this wonderful definition:

The Internet is not something you just dump something on. It’s not a truck. It’s a series of tubes.

So now you know.

Internet Protocol Version 6 is the imminent next generation Internet Protocol, which amongst other things will replace the four byte IPv4 addressing scheme we use now (numbers like 193.1.2.3) with a 16 byte addressing scheme.

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 nearly half the address range is essentially wasted. Ford motor company have more IP addresses available to them than are available to the whole of China!)

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 aggregatable global unicast addresses, which have a total of 61 bits available for addressing, but these bits are split into smaller blocks, as shown

These allow aggregation of the addresses for routing purposes by various authorities. There is a top level aggregation (TLA), next level (NLA) which might be an ISP and site level aggregation (SLA) which could be a company or university or somesuch.

That company can then set up multiple site networks 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 (where I am writing this) 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!

Steve Gibson’s Security Now podcast majors on the story about the new network stack in Windows Vista. This is an interesting story, and an interesting podcast, but when Gibson describes what is meant by a network stack, be warned that he gets a bit muddled.

According to Gibson, the bottom of the TCP/IP stack is the “electrical link layer”. This is wrong. The bottom layer of the stack is the physical layer, and it is the physical layer that cares about the physical medium - the electrics if you like.

Of course it is not strictly true that one needs an electrical physical medium. There have been some novel media implemented in the past.

What has probably confused Gibson is that TCP/IP is not an exact fit for the OSI 7 layer model. Indeed, in an earlier podcast he wondered as to why we had jumped from IPv4 to IPv6, missing out IPv5. He seems unaware that IPv5 was an abortive attempt to rewrite the protocol to conform to the OSI 7 layer model - abandoned on grounds of the cost and difficulty of roll out

So the physical layer is not handled in the TCP/IP stack, but is hived of to the network interface card which also deals with the media access control (MAC) and other parts of the data link layer. The TCP/IP stack interfaces with the hardware through software drivers at the link layer.

The first layer that is wholly part of the TCP/IP network stack shipping with any of the current popular operating systems is the network layer (layer 3), what Stev Gibson calls the IP layer (not without justification. The network layer is the layer that abstracts out lower layers and deals with delivery of IP datagrams across networks).

Gibson calls layer 4 the “protocol layer”. By this he presumably means the layer that handles multiple transport protocols such as UDP, TCP and others. This layer is more usually called the transport layer, and that name will prevent confusion from the overloading of the term “protocol”.

So all in all, an interesting podcast, but don’t get confused by Gibson’s muddled description of the protocol stack

Oh and later in the podcast, Gibson says that Microsofts claim about Vista being the most secure OS yet is a non sequitur. Vista may be fundamentally flawed, but to be a non sequitur there would surely need to be an argument, whereas all Microsoft provide is a claim. But those big latin names for fallacies make it sound like we know what we are talking about don’t they!

Steve Gibson is several years out of date in his Security Now podcast, episode 47. He says:

[The October 2002 DDoS against the DNS]  was directed at all 13 of the main DNS servers, the so-called “root servers,” which maintain the master directories of domain names. Nine of the 13 DNS servers were brought down. Only four of the servers managed to stay on the ‘Net. [...] There really is no defense. The only thing that can be done is that – and this is what some of the commercial anti-denial-of-service service providers have done, is they could have servers connected to very large pipes

Mr Gibson’s analysis is wrong. There is no need for very large pipes to the DNS servers, because since 2002 a program of anycasting has been rolled out for the DNS servers whereby a number of the servers are essentially cloned around the net, and special BGP routes are announced to routers at multiple points across the Internet, such that traffic from a client will be routed to the nearest (in networking terms) DNS root server. This works because packets will be routed to the lowest cost route. It provides failover, because if one server dies, then the next least costly route will be used (which may be another anycast clone).

October 2002 was not the only DDOS attack against the DNS, but of late no attacks have succeeded, because instead of just 13 root servers, we now have many times that number, and we have very successful over provisioning of the root servers.

Last year I wrote this post: http://safle.org/wordpress/?p=4. In particular I looked up the current locations of the root name servers and used the Google Maps API to create this map of where the root name servers are located. The smaller pins show anycast IP duplicate servers. (Note that these are not accurate all the way down to the street level)

The effect of this is that any DDoS against the DNS will be diluted amongst all name servers, and is unlikely to succeed. With every additional anycast clone server, the chances of a successful attack on the DNS are further reduced (and DNS resolution for the new geographic area covered is imporved).

Mr Gibson’s explanation of what the root servers do is also sloppy. These servers do not hold master copys of the domain names. They merely hold data for the TLDs (top level domains) such as uk., us., to., tv., es., ru., … as well as the gTLDs such as com., org.

They used to hold  the next level of edu. I believe, although a quick dig for the edu. name servers quickly reveals this is no longer the case.

Whilst we are talking about this podcast, Steve Gibson gets onto his pet subject - raw sockets in Windows XP. His argument was that raw sockets were a bad idea because they allow someone with admin priveleges (the default user in XP home edition) to run programs that can become worms and the like.

To an extent he was right - but the problem is not raw sockets. The problem is the brain dead decision of Microsoft to continue allowing technically illiterate users run with full admin priveleges on their network connected boxes by default. In Mr Gibson’s dialogue with Microsoft he claims that raw sockets were his one problem with Windows XP. But these were not the problem.

Yes its hard to have backward compatibility without admin priveleges - especially if you are using NT as your operating system. But look at what Apple did with OS X, and you can see how it is quite possible (for a little pain) to make an astoundingly good OS, with backward compatibility and security designed in (thanks to the use of UNIX).

So enough self congratulation in spotting a problem with raw sockets. The question Mr Gibson should be asking is when will Microsoft release an O.S. with security designed in? When will users no longer be logged in with admin priveleges?

 

I sent the following letter to the BT UK Correspondence Centre 3 times. I never once got an answer. I cancelled my BT subscription, but to re-use my efforts, I offer this sorry tale for your amusement.

Dear Sir/Madam

Re. Fault with BT SMTP Service Affecting Our Account

On or about Thursday 26th January 2006, BT Internet reconfigured their SMTP server service manually or automatically in some manner that caused a loss of service from our BT Internet account (xxxxxxxx.x.xxxxxxx@btinternet.com). We use a variety of laptops, desktop PCs and PDAs to access our account, depending on where we are in the house and what we are doing, and the failure affected all of these devices.

The symptoms of the failure were we could no longer send mail, because the SMTP authentication failed. However, we had not reconfigured SMTP authentication, and the password was clearly fine as we could continue to receive mail from the POP3 service, and use web mail.

Online Support

After waiting for a day or two to see if the problem would correct itself, my wife decided to contact technical support on Sunday 29th January, as she had an email she needed to send. She spent a couple of hours with the technical support to no avail. In this time, they made some suggestions that I think, as an ICT professional, were unacceptable, and you will want to review these issues:

1. At no point did the call centre take on board that this was a fault that had simultaneously affected multiple setups on diverse operating systems. When my wife asked if anything had changed on the mail server, she was adamantly told “no”, despite clear evidence to the contrary, and the fact that the call centre were clearly not in a position to know this.
2. On discovering that my wife was using Microsoft Outlook to read email, she was told that as this was not a supported mailer, she should take the issue up with Microsoft! Now this response annoyed me because
   1. the problem was very clearly not with the mail software,
   2. my wife could easily switch to Outlook Express if that is what was necessary,
3. If you say that you only support Outlook Express, and will not help with problems on any other mailer, then you lock yourself into proprietary Microsoft technologies. You are saying that users of other operating systems, handheld devices, text only mailers and mailers used by people with disabilities cannot access technical support. This is probably in breach of your duties under the disabilities discrimination act, and is certainly bad business sense, as you are saying that there is a huge user base that you do not want as customers. You do not seem to want users of open source software, for instance - despite the fact that your SMTP service is itself the open source qmail SMTP server.
4. Your support staff did not tell my wife what she needed to tell Microsoft. Certainly Microsoft have no interest in a sudden loss of service to the BT Internet mail service, and would send the problem straight back to you. This kind of passing-the-buck is not acceptable from a service that should be attempting to help customers resolve problems.

My wife, on my instruction, transferred to Outlook Express and refused to close the support call. After a while, the call centre asked if we had a firewall enabled. Quite sensibly we do run a firewall in our ADSL router, and the support centre suggested we disable it. I immediately disabled the firewall, and in the meantime established the further information that sending mail still worked from our dial up BT Internet account. However the call centre staff would not take our assurances that the firewall was disabled for granted, and informed us that we must contact our firewall vendor!!! Repeated insistence that the firewall was disabled eventually prompted the call centre to give us a telephone number through which we could escalate the fault.

Telephone Support

I called the support centre on Sunday evening to escalate the fault, and despite my telling the operator that we had been through online support, I was asked all the same questions. Yes, I had (grudgingly) booted my Linux laptop into windows and was running Outlook Express. No, we did not have a firewall running, and so on. At this point I was asked what ADSL modem we were using. I indicated that we had an ADSL router, and your call centre staff told me that the router must have a firewall and I needed to contact my vendor!

At this point, please bear in mind that (a) I had disabled the firewall, (b) the router had been working fine to date, and (c) the problem was failure of authentication, not failure to connect to the SMTP server. Again, this is a pass-the-buck attitude to support that must be dealt with. It is quite unacceptable.

I told your operator firmly (but quietly and politely) that the problem was with the BT SMTP server, and that he needed to escalate the fault - that the fault lay in a failure by the SMTP server to accept our fully resolved broadband IP address as a valid relay domain for our credentials. I reiterated that we had been through the online support process, and that the support centre had already been unable to help, and that the problem should be escalated to a suitable engineer. The operator refused to escalate at this point (some 10 minutes into the call) and continued to offer suggestions to fix the problem. I politely continued working with your staff to try various suggestions.

At one point your operator asked me to connect by hand to the SMTP service. This I did (I told him the port numbers as he started mentioning port 110, which is the POP service. Port 25 is SMTP). We quickly established that my communication was fine and I gave him my ADSL IP address. After many suggestions and many long periods of holding, your operator eventually agreed to escalate the fault some 50 minutes after I had place my call.

It seems to me that all companies I deal with who use outsourced support these days require me to speak to them for about an hour before they will eventually admit to pass on a fault to a technical contact. I am unhappy about this, and you really need to consider a means by which technical people can send technical queries to their peers, without this timewasting filter.

I indicated I would be going to bed at this point, and could the technical support engineer call me in the morning. The operator said he would pass on the message. No call was ever returned.

I would like a call credit for the time spent on this call - particularly as your operator refused to escalate the fault, and also because no call back was ever received.

Email Support

On the afternoon of Tuesday 31st January I used the BT web site to send an email about this fault. Prior to sending this email, on Monday night I spent some time investigating the fault, and discovered the following:

I connected by broadband and captured this SMTP session information: (I have obfuscated the base64 encoded password, but otherwise the session is exactly as seen on the SMTP server):

220 smtp810.mail.ukl.yahoo.com ESMTP EHLO eeyore.gloomyplace.org.uk 250-smtp810.mail.ukl.yahoo.com 250-AUTH LOGIN PLAIN XYMCOOKIE 250-PIPELINING 250 8BITMIMEAUTH LOGIN 334 VXNlcm5hbWU6 c3RsalcGdshabi2wLmtJJpzdG9u 334 UGFzc3dvcmQ6 aXblRmsqXQQ= 535 authorization failed (#5.7.0)

The WAN configuration for this connection was:

ppp0 Link encap:Point-Point Protocol inet addr:86.145.210.33 P-t-P:217.32.86.146 Mask:255.255.255.255

According to dig, the IP address 86.145.210.33 resolves as:

22.210.145.86.in-addr.arpa. PTR IN 604800 host86-145-210-22.range86-145.btcentralplus.com.

I then repeated the experiment with the broadband disabled, and connected via dialup. Here is the chat, which you will note succeeds:

220 smtp810.mail.ukl.yahoo.com ESMTP ehlo eeyore.gloomyplace.org.uk 250-smtp810.mail.ukl.yahoo.com 250-AUTH LOGIN PLAIN XYMCOOKIE 250-PIPELINING 250 8BITMIME AUTH LOGIN 334 VXNlcm5hbWU6 c3RlcGsaqhlfdfbdi5wsqasLdsd672 334 UGFzc3dvcmQ6 aXblRdsjkXaQ= 235 ok, go ahead (#2.0.0) ...

The dialup IP/gateway info was:

213.122.53.24/32 gw 213.122.53.24

This IP address resolves to:

24.53.122.213.in-addr.arpa. PTR IN 604800 host213-122-53-24.in-addr.btopenworld.com.

I sent all of this information with various suggestions in the email. I noted that the problem could be in the way that qmail is building its authsenders file (or PAM equivalent), and pointed out that the problem was that the btcentralplus.com. domain was not being listed against my credentials as a valid relay domain.

I then gave you the key information that would have allowed an engineer to resolve this problem. I wrote:

” It may be that this is because my BT Internet email address pre-existed the broadband connection”.

Other than an automated acknowledgement, no reply was ever received to this email.

Eventual Resolution

As BT were not talking to me, I continued my investigations. I noted that there was no huge outcry on Usenet about the failure of BT’s SMTP service, so I presumed that this problem only affected me or a small user group. I considered what was special about my BT account.

One thing that was special was that we have had a BT dialup account for a very long time. Long enough that we retained the five free email address service from our BT anytime account. Recently BT have extended this service to all customers, but it was a service we already had.

However it occurred to me that the automated registration system may treat my account differently from newer accounts with this service, and that you may have reconfigured your SMTP service to disallow the older accounts, or maybe my credentials were simply damaged in your database and needed refreshing.

I thus “upgraded” my account from the existing “five free email address” service to the exact same service! This will have pushed new versions of my credentials around the BT Internet network, and sure enough after a short pause, the SMTP service started authenticating from our broadband IP address once again.

Conclusion

It is now Friday 3rd February. BT have not followed up on my original fault report, nor on my email query. I have managed to resolve my own problem, but only through an in depth knowledge of how these services work. If we had followed your advice, we would now be talking with Microsoft!

I am extremely unhappy with this experience, and have noted various lessons that I believe BT must learn.

As a BT shareholder I am unhappy that you appear to be turning away a large part of your potential user base through your “outlook express only” policy. I am also unhappy that your failure to address such support issues is presumably turning away other customers. I myself am now considering looking for an alternative ISP.

I would like the following undertakings from BT:

1. To refund my call costs for my support call on Sunday Evening;
2. pass on my resolution of your fault to your call centre as soon as possible, so that others affected by this fault can be told quickly how to resolve it;
3. To address the failures in your technical support centre, to ensure that in future, genuine technical issues can be passed onto someone more knowledgeable more quickly. I would like BT to tell me how they intend to achieve this;
4. To ensure that the failure to return calls and emails is addressed;
5. To provide support for cross platform mailers - e.g. Mozilla Thunderbird, and also for text mailers and those used by people with visual difficulties.

I look forward to your considered reply.

Yours faithfully

IPv6 is an important topic, and Steve Gibson pretty much botches it in his Security Now! episode 25.

Now I should add a copule of quick disclaimers: for all the controversy around Steve Gibson (and this is not the Steve Gibson of Truth Driven Thinking incidentally), we should really cut him some slack on this podcast. What he is trying to do on this show 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 maybe the problem is that he is trying to do too much himself. He is setting himself up as an expert in all things, but we know the Jack of all trades is the master of none. Certainly there are often large gaps in his knowledge that would be better filled by bringing in some other expert to discuss the issues of, say, NAT or CSMA/CD.

But on IPv6 Gibson’s gap of knowledge is so large that he fails to direct listeners adequately at all. He writes:

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 Internet Protocol Journal Volume 8, number 3 for more on this.
• 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
• IP address depletion is more imminent than the Steve Gibsons of this world think. We are certainly in the last decade of IPv4, and we may see address depletion in as little as four or five years. Again see the Internet Protocol Journal at http://www.exio.com/web/about/ac123/ac147/archived_issues/ipj_8-3/from_the_editor.html

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.

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.

But whilst the Gibsons of this world stick their head in the sand and pretend this is just not an issue, because we have NAT, we continue to drown in the IPv4 sea.

You want security now? Implement IPv6. Learn how to rewrite your firewalls for IPv6 (yes you need to do that). Learn about its encryption and authentication mechanisms. That is the way to secure networking (well more secure at least).

So in closing - Steve Gibson should keep up his podcast, but until he starts consulting with IT security and networking experts, the podcast will always dissapoint. A pity, as the idea is good.

But I wouldn’t want to do it on my own!