http://advanceddentalmn.com/dental-services/cosmetic-dentistry/ My, how time flies. I completed my CCNP a year ago and as part of the ROUTE and TSHOOT exams, there was coverage of IPv6 but it really felt more like a bolt on, rather than an equivalent study of IPv4. The last IPv4 /8 range has finally been allocated and yet there still appears to be a resistance to transition to the new protocol, instead using black magic to squeeze ever more out of the depleted IPv4 space. In this post, I look at some of the reasons I feel are behind the slow adoption of IPv6.
Kurovskoye So has IPv6 adoption exploded in the last 12 months? The answer is a definite no. I came back from Cisco Live London 2012 having sat in on a few IPv6 sessions and a four hour hands-on lab that, combined, gave me a very comfortable grasp of the protocol. I keenly wrote an implementation plan for the service provider I worked at upon my return. Whilst the number of people in the industry who report they are planning on implementing IPv6 in the next 12 months has increased many fold, the actual number who have implemented it remains a fairly steady and linear growth.
I’m not going to kid on that rolling out IPv6 is a trivial task that everybody should just do, by the end of next week if at all possible, thank you very much. It takes time and planning. Cisco’s own internal IT team, Cisco IT, took over five years to deploy IPv6 across their global estate and they are still working on it. These boys should grasp IPv6 as well as anybody yet they understand that you don’t just slap IPv6 in without some serious thought.
When I presented my implementation plan to the business, it was prioritised and promptly not implemented. Why? Simply because none of our customers were asking for it. Nobody was saying ‘we need services that are only being served up on IPv6’ or ‘we want to offer services to IPv6 only clients’. I look at why this is the wrong perspective later on. So the plan went to the bottom of the priority queue. There were other things we could be doing that visibly brought in money. I suppose in one respect, the good news is that the effort required to implement it was at least understood by the business. Despite my earlier jokey comment, there were no ‘can you have it ready by next week’ expectations.
Ignorance and fear
I think the biggest factor holding up adoption is a combination of both ignorance and fear. People are naturally fearful of change. We aren’t talking about a minor change here either. Add in herd behaviour and you get people avoiding the topic at all costs because they don’t want to be the one that pushed IPv6 on to other people’s already busy schedules.
If you ask anybody who has a certain level of technical knowledge about the biggest risks around IPv6 deployment, you might get some responses back that mention security. Whilst it’s true that IPv6 brings new attack vectors to the party, I don’t believe that it is any more or less secure than IPv4. It all boils down to risk management. If you currently don’t protect your IPv4 infrastructure, then you’ll be no worse off, you’re already doing it wrong. If you do, then you just need to be aware of the newer vulnerabilities and be as vigilant as you currently are.
If you ‘dig’ IPv6, have read up on it and are comfortable working with it, you might possibly forget what it was like before you tackled it so this might all seem like ludicrous behaviour, yet I see it quite often (IPv6 isn’t a unique topic in that respect either). What is the root of this fear? There are a number of factors as I see it and if I was pointing fingers, I’d be pointing them, with various degrees of wagging at:
- The press. How many times have you read a comparison of the IPv6 address space to the number of grains of sand multiplied by the total number of freckles on all the ginger people in the world? Perhaps just once for that specific example, but it seems there are now as many comparisons as there are addresses. We get it. IPv6 has a ridiculously large address space. Let’s not forget the 128 bit length too. Big numbers can carry the wow factor, which is why the press regurgitate them with such vigour, but they can also scare people, for example when somebody gets given a /32 IPv6 address and told to create an addressing scheme from it for their global network
- IETF. I understand that protocols need to adapt but therein lies the rub. I can honestly say that since I first started studying IPv6, and that goes back to my sysadmin days, IPv6 has changed several times over. There have been changes to the address scopes, the usage of /126 – /128 networks, the ICMPv6 implementation, etc. Whilst I would argue that all of the changes I’ve seen have been for the greater good, it strikes fear in to some people, particularly those who are risk averse. In IT, there is an eternal struggle between stability and agility but I don’t think I’d get much argument from people when I say that I like my lower level protocols to be stable. Rightly or wrongly, the transformation that IPv6 has gone through, even in the last three years, let alone since inception, is enough to scare a lot of people away from tackling it. Heck, I know some people who avoid learning about it because ‘it will have changed again in a few months’
- Vendors. We need to cast at least a couple of dirty looks across to the vendors. Even in June 2013, some are not implementing all of the relevant pieces of the IPv6 puzzle so IT houses that utilise that vendor are being forced to hold off for the time being. I’m not just talking about hardware here. There needs to be full interoperability across the board
- Service providers. Quite possibly one of the biggest culprits in my opinion. Build it and they will come. Start coming up with crazy ideas like CGN (Carrier Grade NAT) and you’ll just create a world of pain further down the road. That’s the equivalent of taking a rug from a dump site and trying to brush the rest of the dump under it. Taking my analogy further, I guess I’m proposing building a brand new dump, which doesn’t really sell it…but regardless, service providers need to start pulling their fingers out. Not only do the big boys need to be running it across their core, which I’m confident most already do, but companies who offer Internet services to consumers should have IPv6 as a highly visible and preferred option
- You and me. By sheer size of numbers, I place a fair chunk of responsibility with the people working at the coal face. The network engineers, the developers, the sysadmins. Yes, it might seem like a scary proposition but it isn’t going to implement itself and the requirement isn’t going to go away. So even if you have no demand at the moment, believe me, you need to get planning regardless. When that demand comes in, you need to be able to deliver and support or else you will be left behind. There is lots of talk about the industry holding up IPv6 deployment. Well guess what? You and I are a part of that industry so let us all accept some responsibility and look at how we can overcome the obstacles. I don’t think anybody can afford to sit back and think the problem will resolve itself and please don’t be of the mindset that this isn’t going to happen in your working career
Earlier I talked about deploying IPv6 to get to IPv6 content and mentioned this is the wrong way of looking at things, certainly at this time. The current need to move to IPv6 is due to the lack of available IPv4 addresses, pure and simple. As far as I’m aware, there isn’t a whole lot of IPv6 exclusive content out there. However, the sooner we can get everything dual stacked, running IPv4 and IPv6, the sooner we can retire IPv4 and then IPv6 really comes in to it’s own.
IPv6 isn’t a flash in the pan. It’s a protocol borne out of necessity but it offers so much more than what IPv4 currently does. Burying your head in the sand won’t make it go away. There is no better time than now to get familiar with it. Watch this space for a high level planning post that will hopefully give you a starting point. After all, they say that a journey of 340 undecillion miles begins with a single step.
Till the next time.