IPV6: The New Y2K Bug, Will Bite YOU!
I get calls for help, from other web developers from time to time, thanks to my backend server and database experience. But this caller was different. He said he thought he might need a voodoo doctor or psychiatrist, but he was giving me “first shot” at the problem.
While I pondered whether I would prefer being thought of as a voodoo doctor or a shrink, the caller explained that the “problem” was that his client was about to fire him because he couldn’t solve an issue where his client thought he was losing “Contact Us” messages.
People would tell this client they would have bought from him but he didn’t respond when they filled out his contact form.
My caller, let’s call him “Derek”, spent a full day, thoroughly testing on Windows, Mac and Linux systems, using every browser each system would support and at no time was a contact message ever lost. “So that proves that people are just pulling my client’s leg, right?
Maybe. Maybe not. Derek changed a lot of variables in his testing, but what variable or variables was he not changing?
I.P. address seemed like an obvious place to begin. So, I turned to my good friend, Google and found this –
Bingo! Solution found in under five minutes. Thank you, “VentureBeat.com”, Brett Exnowski and Primitive Spark! Brett did all the hard work and was kind enough to share with the rest of the WordPress world. We all owe a huge “Thanks!” to Brett Exnowski.
The way WordPress works is that if any data doesn’t match the database field specs, then the entire dataset is tossed out with nary a notice, not even in the error log!
Although the particular manner in which this problem manifests in WordPress, this is not a WordPress issue in general. This is a global internet/networking issue.
IPV4 has been the standard I.P. address format since the Internet’s “Genesis”. But as we began running out of available I.P. numbers, a new standard was created – IPV6.
But we all felt that IPV6 was so far in the future, that many – actually most – of us ignored it and continued to code for IPV4. This chart shows how IPV6 adaptation is suddenly skyrocketing.
While IPV4 required 15 characters, IPV6 – according to the linked article and many other sources – requires 39 characters. And this is the crux of the problem. But wait!
Not So Fast!
If you take networking courses, as I have, you’ll learn that to properly setup a database to store IPV6 you actually need 45 characters (IPV4-mapped IPV6).
Since my CompuSolver Blog is not exactly a top-ranked WordPress blog, it is quite likely that the few plugin developers who hear of this problem and try to fix their plugins will increase the IP field length to 39 characters (instead of 45) and may still occasionally lose data.
“Lose data”, in Derek’s client’s language translates into “lose customers; lose business; lose money”.
The solution is to find every data table that has a field (column) for IP data, and increase its maximum length to 45. Note that some tables may have an IP field set as CHAR(15) and some as VARCHAR(15) (or change ’15’ to 20, 25, etc.). So that just checking all VARCHAR fields isn’t enough.
Also, it won’t really hurt to set IP fields to VARCHAR(50) or even 100, since the performance optimization difference will be very minor.
How many plugins are affected? Brett did a search which omitted 20% of plugins and still found hundreds of plugins that were affected by this IPV6 bug. I scanned the list and recognized roughly a dozen that some of my clients were using.
Since I don’t charge my currently hosted clients for fixes like this, I was looking at a lot of work to do, basically for free. As a lazy guy who is pretty much allergic to “free” (but not to “cheap”), I decided to write a script to do the work for me.
Maybe I’ll turn that into a plugin. Anyone interested?