The Short Version (recommendations and opinions)
There’s no marketing or technical need for IPv6 in the current product in the next 1-3 years. There would be significant costs(1) associated with adding complex networking code at the lowest levels of a stable product.
Don’t do it.
So don’t do IPv6, then?
I didn’t say that. I said, “don’t add it to the existing product.” Given the known architectural and quantitative (data volume) limitations in the existing products, build a new version of CygNet (CygNext) that supports IPv6 (only(1)) and Unicode/DBCS. This would allow us to enter all likely international markets (India & China) which not coincidentally are the customer bases driving the adoption of IPv6, primarily due to the impending exhaustion of IPv4 address.
CygNext would also be designed to allow several (TBD) orders of magnitude more data, more types of data (e.g. video, audio, analog streams), integration with customer security infrastructure, SOA features, and a wider variety of UI/HMI development options.
For the moment we’re going to put this on a back burner and move on to some other projects.
(1) There is no way to add v6 code without updating/changing existing v4 code and incurring non-trivial testing costs. Forking the codebase to support separate v4 and v6 versions would consume amounts of extremely scarce developer (familiar with network code) time.
(2) – Based on the assumption that greenfield SCADA operations in developing markets will be using new, IPv6-capable sensor/net technologies. We would probably need to build an IPv4-IPv6 gateway service (at additional cost) to support customers who have older devices.
The Longer Version
The story to date
I’ve spent the past months working on understanding how we use IPv4, how IPv6 works, how one deals with IPv6 infrastructure, and what it would take to add IPv6 to the existing IPv4 CygNet in such a way as to keep a single code-base and allow the operation of CygNet in either v4 or v6 mode (but not both).
This involved a lot of reading. A lot. More than that. Srsly. My brain hurts, and one reason is due to the immaturity of the IPv6 marketplace.
After that, lots of coding. And recoding.
In the end, I did not have a running version of the ARS or the networking library that could use IPv6, but we learned a lot.
Coding, coding, coding
Nothing like being dumped in the base of the Sears Tower with faded, 20-year old blueprints and told to fix the building so aquatic mammals can live there. As much as anything I’ve ever done, this was incredibly interesting. The code in the base of CygNet is only C++ in name. It’s really C and it’s really tight, nicely written. But…it’s old and hairy, and I am young and innocent in the ways of networking. Oh…wait, no I’m not. 🙂
The most important thing* to know about the guts of our networking is a class called CAddressBytes. It’s a vector (aka array), because there no reason not to treat a v4 address as a series of 4 characters (e.g. 192.168.1.1). In fact it’s 16-bytes long because that’s the size of the standard data structure used to keep track of v4 hosts.
The minimum size data structure for IPv6 is 28 bytes. For the non-programmers and non-accountants I’ll point out that 16 is not equal to 28, not even for Extremely Large Values of 16. This is a Big Problem because we have to store information about hosts, and everything, everything, *everything* is built around the not-so-secret knowledge that an address is 16-bytes long.
Jeff pointed out some places where we had “extra” space in the networking structs left over from the days of Banyan Networking, but by and large it was a bit of a maze. For the limited purposes of experimentation, this would probably be adequate. For complete implementation, though, it looks as though there’s no way to get around needing to extend the size of various structures in ways that would make it difficult to retain compatibility with a pure (current) v4 implementation.
I believe, too, that a case could be made for converting the CAddressByte class from a vector to something more like an actual IP address object, especially since the future of networking will almost certainly involve networks wherein hosts/hostnames and IP addresses have a Many-To-Many relationship, something that we categorically cannot deal with in the current code. Clusters, clouds, and other forms of distributed computing represent a next-gen level of architectural complexity that cannot be adequately dealt with using a simple, small vector.
We tried both ways, that is, extending the size of the vector and actually switching the base type to SOCKADDR_STORAGE, and each approach had problems I’ve detailed in past posts.
*of the many Most Important Things, that is
It’s a Special Feeling
Try to buy IPv6 from your ISP. Go ahead. I’ll just have a cup of coffee while you try it.
All done? Yeah, that’s what I thought. You can’t buy it. I can’t. Almost no one can. On the rare occasions you can get someone at a major ISP (e.g. Time Warner Business Cable) who even knows what it is, they tend to say something like, “No one’s asking for it.”
“I’m asking for it,” you say.
“Well, you don’t count, and besides, since no one else offers it, we’re going to wait until they do.”
Catch-22, Turing flavoured. Oh, and that “special feeling” I mentioned? It’s anger. And rage. And frustration.
I was eventually able to route v6 packets by signing up with a tunneling host provider, meaning that my packets went from my network to someplace in Chicago, where a miracle occurred and they then showed up in Los Angeles, to be carried the rest of the way to the research server’s external (public) IP address.
My current opinion
It’s an informed opinion, but still an opinion. I can think of no likely technical justification for adding IPv6 to the existing version of CygNet.
It will require updating existing code, and adding new code. This increase the likelihood of problems with IPv4 networking, while adding the certainty of running into problems with IPv6 networking, and since v6 is effectively a new standard, there are going to be problems, no question about it.
Existing customers are unlikely to switch out IPv4 for IPv6 on their SCADA networks for several reasons (most of which boil down to cost):
- Existing legacy technologies that cannot be upgraded. 20-year old devices are apparently not uncommon in our existing customer installations. In 1990, we were still debating whether TCP/IP was going to be the “winner” in the protocol wars.
- The use of NATted IPv4 infrastructure eliminates the need for IPv6’s increased address space. Since neither we nor they have applications in place or in planning that need v6-specific n-cast or routing features, there’s no compelling technical need.
- IPv4 can be carried over IPv6, and will have to be in order to deal with legacy devices.