In some organizations we work with a certain state of IPv6 deployment has been reached in the interim which includes, among others, the following aspects:
- the network infrastructure is IPv6-enabled (incl. interface addressing, routing [protocols] and the like).
- parts of supporting services (security functions, monitoring, system management) include IPv6 in a proper way.
- 3rd party providers have been contractually obliged to deliver their services in an “IPv6-enabled” mode (as opposed to only being “IPv6-capable” which was the standard requirement in many RFIs during earlier years).
It might then happen that networking people (who often are the initial motivators for deploying IPv6) in such organizations are stating, when asked about IPv6: “it’s [mostly] done”.
Point is that, alas, this does not necessarily mean that a single service or application is *actually using* IPv6, so while the above certainly constitutes an achievement it might not even be halfway through.
Often enabling IPv6 for applications/services usually is a bit more difficult than enabling it on the infrastructure level, for several reasons:
- higher degree of (to phrase it in a positive way) autonomy or siloization in the application space.
- less understanding of IPv6, potentially coupled with a stance like “that’s something that [exclusively] affects the networking folks, hence they will take care of this”.
- less perceived or actual incentives to enable IPv6 (e.g. they might not care about running out of IPv4 addresses).
So this raises the question: from the perspective of “driving IPv6 within the organization”, how to proceed from here?
Some organizations we know have started performing surveys to find out about the IPv6 readiness/openness among the application or service owners. This can not only help to gather a better understanding of where the organization stands and what next steps could look like, but it might also establish a communication channel with the right people.
One flavor of such surveys consists of very technical, application-specific questions (I will discuss another flavor in a follow-up post). Such an approach should be accompanied by educational efforts, not least as the questions and/or IPv6 in general might otherwise not be comprehensible for the audience. Also it should be kept in mind that such surveys pretty much always are implemented in a web-based manner which usually restricts the format of the questions or answers. Hence it can be reasonable to spend some intellectual energy on what you actually want to learn from a survey and how this is realized by means of the survey in question. Lastly thinking about the way the collected data is stored and if/how often the survey is repeated (think “measuring progress”) can be helpful.
These are some thoughts from efforts we’ve been involved in. A slightly reduced/sanitized example of an application-centric survey can be found here (it’s an early version I developed in 2017 but this is a format which can be easily shared).
Happy to hear your thoughts or to get feedback on any channel. Stay tuned,