Wouldn’t it be nice if turning on IPv6 really was ‘press one button and the rest is magic’ easy?
For some things, it is. If you’re talking about client-side, enabling an IPv4-only home service on DSL or fibre really can be this simple, because all the heavy lifting is being done inside your ISP: you’re not enabling IPv6 in the network, you’re turning on the last mile. It was knocking at your door and you just had to let it in.1
And, if you are a user of compiled systems, programs, it’s usually easy: you just run code which says it’s already IPv6-aware, or ask your vendor to modify it. After all, “they all work nowadays, don’t they? Don’t they?” Really?2
But spare a thought for two different places with work to do to enable IPv6: your ISP, and software developers. Those assumptions I stated above about ‘easy-as’ don’t apply for the people behind the curtain, making it work – as discussed on Reddit last week.
ISPs have two things to do when they enable IPv6
The simple thing to do is to enable it inside their own network. It’s simple in as much as it’s understood what has to be done. But it’s not necessarily easy, and the distinction is important.
This really is a well-understood problem these days with several well-understood, nation-scale examples to choose from: Equador, Comcast / T-Mobile / AT&T / Time Warner, Sky, SKTelecom can all show this can be done at scale. It’s not exactly one-click, but it’s no longer a large amount of unknowns and a small amount of known issues: it has become a large amount of known processes, and a small amount of corner cases. But some corner cases (like Skype) are not easy to fix (only Microsoft can fix Skype).
The harder task for ISPs is changing the Operations Support Systems and Business Support Systems – or OSS and BSS. These are the software systems which provide services and, importantly, manage billing and charging.
OSS and BSS challenges are easy to identify, but hard to resolve. The OSS and BSS may be the primary value that the ISP has as their own investment in running the network. If not purely in-house developed, this is very unlikely to be an off-the-shelf solution bought unchanged from an external supplier: it’s much more likely to be a very large, complex, and ageing suite of mutually incompatible systems interacting in different ways.
I’ve seen this in at least two ISPs, both former national monopoly telcos, and in one case, they continue to use IBM 3720 Terminal emulation to drive mainframe applications. In the other, they had at least two different web-based systems to reconcile two distinct software suites behind the scene, each providing part of the solution to commission a new customer.
It’s not uncommon to have three, four or more different provisioning systems live at the same time (each acquired sub-company may still run inside the main brand) and to have to re-enter data into each, for instance.
For example: consider if your billing mechanism is designed to count IPv4 packets using SNMP interface statistics, and you now have two reporting lines in your SNMP, one for IPv4, and one for IPv6? It’s possible that you have to do significant work to capture the IPv6 count. Or, perhaps you have a DHCP IPv4 pool, and therefore do no assignment to specific customer endpoints. But your architects decide to allocate a static IPv6 /56 (this is a common design goal), which now has to be handed out, per customer, from the point of account creation all the way down to the customer’s service going live. How does that work? Do you retrofit a new function into your OSS?
And if the client wants services to run end-to-end to the IPv6 addresses, it’s not impossible that, as the ISP, you will also now need to manage reverse DNS delegations. Where previously you had a simpler model for IPv4 which left reverse DNS as a defined, static list of 255 names per /24. In IPv6 you really don’t want to try and pre-populate the entire reverse DNS map! It’s much more likely that you are going to have to engineer a reverse DNS delegation mechanism, or else do some kind of on-the-fly DNS creation.
Let’s now consider software developers
Imagine you are a software developer and you have a large, mature product which is targeting the online world, and you have written it to use the MySQL database back-end, believing that IP addresses are short strings of at most 15 characters (4 sets of 0 through 255, and three separating full stops) and IP prefixes are at most 18 (an additional “/” marker and a length of up to 2 digits size, encoding 0 to 32).
But now, you have to cope with syntactically detecting IPv6 addresses (new format, new characters “:”) and they’re now 39 bytes long, or 43 if you have /128 addresses. Worse yet, while there are primitives built into MySQL to handle IPv4, they don’t handle IPv6. So a bunch of SQL logic you wrote a good few years ago now has to be re-visited.
This isn’t a hard problem but it’s not exactly easy or simple. It’s easy to say “find all the places you assumed an IPv4 address and change them to be either an IPv4 or an IPv6 address” but it turns out that in many applications, this means quite a bit more work. For example, inputs supplied by users are often type-checked: simple syntactic review of the contents, to determine if it’s legally of the right type. If you only fix the database, you may leave the code unchanged. This would reject an IPv6 address being entered, because the type-checking on values for an IPv4 address only has to recognize full stops and the digits 0 to 9, where the IPv6 code has to recognize additionally the letters ‘a to f’ in upper and lower case, and the colon ‘:’ character. So, even the user interface-code has to change if you do any kind of input type-checking.
Or, maybe your code works directly into the TCP/IP and Sockets() interface. If you are operating down at this level, you will already know about RFC3493 but for those who don’t usually code at this level, you will be taking code written to use older constructs, and calls. Your code very probably doesn’t call the getaddrinfo() or inet_pton() and inet_ntop() functions, but uses older calls and structures which fatally assume IPv4 only.
There is a lot of documentation online to re-write this code for C. There are lots of examples. But, you may dread re-opening the door to this legacy code, because one of the definitions of “legacy” often quoted by software developers, is “the code you are too scared to work on, in case it breaks and you cannot fix it”. And it’s certainly likely the systems which you depend on, and have done these years gone by, pre-date a need to operate with IPv6.
All this is well known. There is nothing new here, we’ve been telling people for a long time about the problem, and how to deal with it. But now, it’s real.
So spare a thought for those working behind the curtain – those who now need to work their magic so everyday users can simply ‘press one button’.
Footnotes
1. Actually, my own recent experience moving from an ADSL2+ dualstack service to the Australian NBN fibre dualstack service was a little fraught: it turns out that sometimes you need open source software, and I had to replace my factory image with a free OpenWRT instance to get it to work.
2. Again, this is more mostly-true. There are going to be corner case applications which don’t work well on IPv6 yet (Skype for instance) but in the main, most modern applications on either Windows, OSX or iOS/Android are going to be ok. The ones which aren’t ok, are very quickly coming to the fore, because we now have significant IPv6-preferencing networks in the USA which drives a lot of market decisions in applications development.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.