Broader Testing Services as the Cloud and More Evolve

What’s new as the number of nodes in the data center continues to grow

Editor’s Note: “What we are seeing now, because we have run out of IPv4 addresses, is that service providers deploying networks want IPv6-only networks,” Timothy Winters, Senior Executive, Software and IP Networking at the University of New Hampshire InterOperability Laboratory (UNH-IOL), tells EECatalog. Winters spoke with me following the lab’s announcement that its broadened testing services  align with  the National Institute of Standards and Technology (NIST) revamped USGv6 profile. As UNH-IOL co-authored the new profile, I wanted to hear Winters’ perspective on the update. Edited excerpts of our conversation follow.

EECatalog: What are some of the things the NIST update of the USGv6 profile achieves?

Timothy Winters (TW): Besides including all the updates from the IETF, we wanted to break the profile up and move some of the U.S. government specific components out of it. By making it more generic it allows governments in other countries or even just larger user groups to use the profile. Now it’s possible to use parts of the profile more easily and interchangeably. In addition, it helps the vendor community. They avoid having to test IPv6 in multiple ways, it would allow testing once and applying to multiple programs.

We also added new specifications for components and capabilities which are new since the first profile. That includes things such as IoT and transition mechanisms—10 years ago the mechanisms were very much trying to make v6 work over v4. What we are seeing now, because we have run out of v4 addresses, is that service providers deploying networks want v6-only networks. And because of that we need transition mechanisms now to make v4 work over v6.

Last but not least, while the original profile  mentioned applications; the updated USGv6 profile has a much better definition for promoting applications and services including cloud services.

EECatalog: What are some of the ways the Interoperability Lab has updated its testing services to meet the requirements of the new profile?

TW: We set up testbeds here at the IOL that are on v6 only networks because we want to make sure that an application can work. Whether for managing an install or doing an update what we don’t want is for someone to buy something and then try to put it on a v6 only network only to realize they have to connect to a data base or an install software that is only available over v4.

EECatalog: Could you speak to how things have changed with the growth of cloud services?

TW: Government  agencies want to be confident that the applications they purchase will continue to work when connecting to the cloud. So, while we are not testing the innards of the cloud—Amazon or Azure or Google Cloud Computing or Oracle or whatever it might be—we are testing whether an application,  a web browser, a phone here at the lab, can connect to that service in a v6-only environment.

So, we set it up here at UNH-IOL as v6 only to make sure they can still get to the services. Or, if things don’t work, we can tell the application vendor, “Hey, we noticed that this feature doesn’t work on your device; you can’t do an update on the fly because you require v4 connection.” Are the kinds of things that we need to test.

And in this case, we’re just accessing those publicly available services. We access those services over v6 only cloud to try to help promote that the external connections to support v6.

What happens in the cloud is like the kitchen we don’t see while we’re dining in the restaurant—it’s hidden away. But what we are trying to do is expose the external interface and support IPv6.

ECatalog: How does having the support of a testing infrastructure serve companies’ interests?

TW: Many companies have gone to Agile methodologies, which enable those companies to release products at a faster rate. At the same time, though, the companies  need a testing infrastructure to support that more rapid release rate. So, we have made our software available to our customers. Most of them take it and roll it into their continuous integration, so that as they are developing, they are testing as they go. That’s a change for many of our customers from five years ago or so.

While we were giving the production code, we would give it at certain points and only at so many weeks. Now,  with most of our tools available to our customers, they are integrating them in-house and making sure that they meet these requirements as they go along, saving money by avoiding mistakes that could cause them problems when it comes to testing.

EECatalog: With the new IPv6 profile, will data centers find they have more latitude, flexibility, and security?

TW: Although we  have seen slow adoption in the enterprise space for IPv6, in the data center we have seen quick adoption, and a lot of that has to do with the number of nodes they have.

It is a lot easier to address a large number of nodes  when you have all those v6 addresses to use. And, data center operators are quickly finding that they can easily segment sections of their data centers using IPv6 addresses. They can give multiple services different address prefixes, making it easier for them to decide the best possible path for packets.  Being able to use IPv6 addresses opened up some doors for them in coming up with unique ways to communicate inside the data center.

EECatalog: Is the Industrial IoT finding it has more and more in common with the data center?

TW: We see a little bit of truth in that. Looking at the IP layer, we have seen that many technologies which in the past did not support IP have started to support connecting their IoT devices over an IP network.

From that perspective, they suddenly do get a lot closer. And anytime you are putting IP addresses on devices which can connect—whether it is to cloud services or a sensor—the more gateways you have, the more difficult it becomes. If you can get native IPv6 out to something from an IoT perspective, it can be very helpful.

Also, we have more than enough address space that can be  global routable so that connections can be be end to end.

We have seen a little bit of movement in the Industrial IoT space, sometimes in areas such as IPv6 running over low power networks . The Industrial IoT sector  is a younger space for us and for v6 in general. They are starting to move over some low powered technologies. They have run over Bluetooth or Z-wave for example, and are now starting to move into the much lower power NB-IoT, SigFOX, LoRa, and looking into making IPv6 work with those technologies.

From an IP perspective, once you begin getting serious about making things reachable from far away (and there are a lot of use cases for doing that) IPv6 naturally comes up because it’s a standardized way for things to talk to one another.

EECatalog: Anything to add before we wrap up?

TW: One of the advantages of being here at the University is that we do have a lot of young engineers. There are 100 graduate students that work here and 25 to 30 of them work on IPv6. Because of this program they are getting access to the latest embedded systems that  might come in and the opportunity to do testing, whether it’s a camera, sensor, data center devices, whatever it might be—they are getting access to those and learning how to use them from a v6 perspective; how to set them up. This program helps the next generation of network engineers.


Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.