This article is more than 1 year old

The internet just BROKE under its own weight – we explain how

Next time, big biz, listen to your network admin

This is the beginning, not the end: There's more looming

Unfortunately, despite any understandable anti-corporate angst I might maintain, 512KDay was completely avoidable, and – mark my words – this is the beginning, not the end.

Another looming problem is IPv6. Millions of small and medium businesses today use two internet links and a simple IPv4 NAT router to provide redundancy and failover. Everything behind the NAT router keeps the same IP; only the edge IP changes if things go pear-shaped.

With IPv6 NAT functionally banned by the ivory tower types who designed the protocol, currently, there is no neat solution to this in IPv6. Existing doctrine states that SMBs should simply get an AS number, get their own subnet and then manage and maintain their own BGP routers, announcing routes to both ISPs.

Putting aside for one moment that most SMB-facing ISPs won't allow BGP across low margin links, the above 512KDay issues should demonstrate adequately that the very concept is completely bleeping batbleep insane.

The largest companies in the world – and internet service providers around the world – failed to listen to the best trained network engineers in the world. Dolly's automated doughnut emporium and internet-driven robobakery is not going to have talent or resources anywhere near what those organisations have to offer.

Oh, there are proposals that state "in a perfect world where everyone throws out every computer, router and application they have, everything will understand the concept of multiple addresses, multiple paths, and redundancy. Assuming we all agree on this RFC and then implement it." We haven't all agreed on an RFC, and anyone who thinks the world is chucking its entire installed base of IT to achieve in IPv6 what was a fire-and-forget $150 dual-port WAN under IPv4 is barking mad.

Alternately, we could abandon the idea of maintaining address coherency internal to our networks altogether and become utterly and completely dependent on DNS, even integral to our own networks and even for such critical bits of our infrastructure as basic management and diagnostic tools.

And what if it all comes crumbling down?

Absolute DNS reliance is madness. DNS does fail. Even if you are made out of super-macho certifications and have nerd cred that ripples like a steroid-abusing superman's muscles at the gym. It fails for the same sorts of reasons that 512KDay bit us in our collective proverbial: human error.

Human beings make mistakes. We make the wrong call. We don't spend money where we should and we spend money where we shouldn't. Hindsight is 20/20 and foresight far more hazy, and sometimes we take what we think is an "acceptable risk" only to have it turn out to be the thing that bites us.

If 512KDay should teach us anything, it is that no single point of failure is acceptable, no matter the size of your business. Yet we also need to bear in mind that not all businesses are Fortune 500 companies with the GDP of Brunei to spend on networking every year.

If you bet your company on cloud computing to be the thing that enables you to operate, there was a good chance that 512KDay was a cold splash of reality when compared to the smooth marketing promises of unbeatable reliability and 24/7 availability. What good is cloud anything if the network connecting you to it fails?

In a similar vein, the series of bad and worse choices for SMBs looking to implement IPv6 will lead many of them to choose single points of failure even if they don't want to. Absolute reliance on DNS or a single ISP could cost them in the future.

What of the other as yet unknown vulnerabilities? Arbitrary limits and the design-by-fiat decisions that simply tell significant (but usually not well-heeled) chunks of the world to take a hike? Will we, as an industry, learn anything from 512KDay, or will we continue along as though nothing is wrong, blaming anyone and everyone except those who actually have the ability to affect change?

I leave you with a quote from Upton Sinclair: "It is difficult to get a man to understand something, when his salary depends upon his not understanding it."

512KDay was avoidable. Will we choose to avoid the next one? Answers in the comments, please. ®

* For the record, using DPI on RDP sessions is just rude. El Reg notes that we cannot confirm this is Shaw's practice. We have put several questions to the firm and will update when we hear more.

See realtime routes from CIDR here and more graphs on how 512KDay unfolded here.

More about

TIP US OFF

Send us news


Other stories you might like