If we just accept "networks are unreliable and sometimes broken" as a fact of life, things will never get better. I applaud the unsung heroes who are finding and fixing the actual root causes of lower layers of our networks. Other important networking issues that come to mind are bufferbloat and IPv6 brokenness.
I'm sure it will be fixed if this stays on the front page for a while, so be sure to upvote the article.
As developers, this should always be a fact of life. True, we should strive for making the networks perfect, but at the end of the day, these things still need to be accounted for.
Because you don't have control over a client deciding that 50 cent network cards are "good enough" for their deployment even though they've demanded five 9's uptime from your software.
Because you can't know when someone's going to spill beer on the switch.
Because someone's just going to pull the wrong cable.
Because the water company accidentally cut the line into the building.
As a sysadmin, I do my best to make the network as damn near perfect as possible; but as a developer, I still generally assume the network is unreliable and plan accordingly.
If you can't guarantee that every layer below you is absolutely reliable, then you need to assume that everything below you might be broken, and that you need to handle it. You can't start with the mindset that everything works below you, and have everything above you also work fine.
The fact that we have people with the mindset that everything below them is broken is the entire reason that these kinds of issues get detected and fixed.
EDIT: I suppose you could rewrite TCP MSS on your own firewall or drop MTU on all web servers.... but of course if you're going to reconfigure your firewall / intefaces, you may as well just fix the problem - which was caused by poor device configuration in the first place.
It's not like it's an "unreliable connection" which can be worked around with error correction. It's a "broken connection", which needs to be fixed.
http://www.datacenterknowledge.com/archives/2009/10/22/peeri...
Basically, Hurricane Electric and Cogent (two major transit providers) are refusing to exchange IPv6 traffic. That breaks stuff. For me the problem manifested as a user facing a 20 second delay whenever he ssh'd in (over IPv4). (I'm on Hurricane Electric. The reverse DNS for his IPv4 address is served by Cogent DNS servers. Reverse DNS lookups were trying to access the Cogent name server over IPv6 and had to time out before IPv4 was tried.)
Other than that though, I actually haven't encountered very much IPv6 breakage.
Peering disputes are problematic for both IPv4 and IPv6. This has nothing at all to do with the IP version!
(p.s. You do realise that the article you linked to is from 2009 ...)
That being said, if you are single homed on HE only then I would suggest you purchase transit elsewhere as well, or find a datacenter that has multiple transit providers. Being single home is dangerous.
The real question is going to be how long can Cogent hold-out. HE is willing to provide them free IPv6 peering, why not accept it so that their customers can get a full IPv6 table...