My response to this article by idiot Melvyn Wray.
I hope you aren't paid to write for this website. If so, you need to be fired immediately.
2000 wasn't a meltdown because corporations the world over spent BILLIONS on their software and infrastructure. The company for which I was working at the time started hiring contract programmers in 1994 and still crossed their fingers hoping it would be enough time to audit and rewrite millions of lines of code.
My current company has allocated around $10 million dollars in infrastructure over the next couple of years. As an ISP, you'd think we'd be able to find SOMEONE with a turnkey solution to give us a smooth ipv6 migration path. Instead, despite the imminence of ipv6, we're starting to feel like pioneers in the industry, a position that we do not desire in the least. For example, there are currently NO vendors offering a full-featured large scale nat solution to buy us some time to get fully underway with ipv6. When you ask any of them about PCP, you're met with blank stares or "why would anyone want to do that?" Granted, the initial draft of the IETF document was written only a month or so ago, ( https://datatracker.ietf.org/doc/draft-ietf-pcp-base/ ) but it should not be the burden of us as the customer to explain why this is critical to a vendor who is boasting that they have the best LSN solution.
The burden is on us to come up with a solution that allows our customers to access both ipv6 addresses as well as ipv4 addresses for at least the next decade. I'd ask you to think of the ramifications of that task, but you're not capable. Suffice it to say, for the forseeable future, access to both ipv4 and ipv6 is mission critical.
Every single piece of hardware serving customers is affected. Every cable modem earlier than docsis 3.0 needs to eventually be replaced. Every cable tv set top box will eventually need to be replaced. Not only does the cable modem need to be replaced, we're discussing the very real possibility of having to put a nat/fw at each customer premises. The reason for this? If, today, you walk into your local Staples, Best Buy, Dixon's, or Curry's, *almost none* of their devices are fully ipv6 capable. Are you the one who is willing to tell the customer that, sure, your Roku, Tivo, Slingbox, Kindle, iPod, wifi Galaxy Tab, Xbox, Wii, Airport Extreme, and Magic Jack will all definitely work with ipv6? You'd bet your paycheck on it?
Every one of our servers needs some attention because even the most recent 5.x version, Red Hat Enterprise and their glorious patch hostage business model is *STILL* based on linux kernel 2.6.18, which has some ipv6 related weaknesses. Every piece of software that serves our customers needs at least some rewriting, especially with regards to anti-spam. There is very little in the way of good, solid support for ipv6 blacklists. The author of rbldnsd, for example, just committed some early support for ipv6 in his code a little over a week ago. It's just enough to get us some working blacklist functionality.
Many of the most expensive pieces of our core networking infrastructure needs to be replaced. While Cisco may have stamped "ipv6 ready" on the side of much of their gear, the act of turning on ipv6 support nearly brings the box to its knees. The reason is because instead of having each line card being capable of hardware flows that require very little interaction with the supervisor engine, ipv6 is implemented in software-only, so suddenly every single packet needs to be sent to the supervisor card for handling. This alone may cost us millions. We're by no means a Cisco-only shop, so we're hoping that our testing doesn't reveal too many more surprises like this.
And you've obviously been reading nothing but puff pieces regarding ipv6 and security. While it has a small number of nice features, it offers not one single bit of increased security that should cause ANYONE to breathe easier. If anything, it should stress people out even more. We're going to be finding fundamental flaws in the handling of ipv6 for years to come. As recently as a couple of years ago, I discovered a critical flaw with the version of glibc that openSUSE was using at the time and it's handling of AF_INET, AF_INET6, and AF_UNSPEC. It was easily missed because this flaw only surfaced when interacting with oddly behaving DNS servers and so only affected, at best, 1% of their userbase. To my knowledge, no one ever figured out the entire cause in any sort of forensic detail, and was eventually fixed.
This also glosses over a very serious shortcoming in ipv6 to which none of the original designers are willing to admit. The problem is that ipv6 was designed in the early to mid 90's, when nat didn't even exist. While the designers lauded themselves for guaranteeing that everything could have a public, internet facing ip address, they forgot to take into consideration whether or not everything *should* have a public, internet facing ip address. Do you think the hacker's at the recent Pwn2Own conference were balked in any way by ipv6? Do you think the recent, critical icon vulnerability in Windows is in any way stopped by ipv6? Does the display of a favicon.ico file that exploits this vulnerability somehow become subverted because it was loaded from an ipv6 website? Using nat provides a fundamental level of security that truly makes the internet a safer place. Insisting, even despite proof to the contrary, that every device should be accessible via the internet is just plain wrong, no matter how many phd's can't get their own heads out of their asses.
All you're aware of is the little bit of a golf ball sized chunk of ice that you've been able to perceive. The reality of the iceberg underneath is absolutely cause for alarm. Keep your finger pointing and chicken little accusations to yourself and let the big boys who do the real work take care of business.
Here's to your writing success in a field other than technology.
#EPIC #FAIL
No comments:
Post a Comment