IPv6 Act Now

My name is Maria Häll and I work as a Deputy Director for the Ministry of Enterprise, Energy and Communications. I work with IT policy, so our department of IT policy, we are about 17 people, civil servants, working for our IT Minister, Åsa Torstensson.

I think that IPv6 development and the transformation from IPv4 to IPv6, this development it’s necessary for the government, in some way or another, be interested in or engage us is. The telco area, the Internet area and this IT policy area actually are the private sector’s area.

That doesn’t mean that the government shouldn’t do anything. We need to know what’s happening, because we’re actually dealing with tax money here, so it’s important that the steps we take, it’s really going to be the best thing to do with the money we have. And to be able to know that, of course, we need to have a very tight and good dialogue with all the market players, and that’s one of the reasons I think it’s been so important having this
Cooperation Working Group, working with the RIPE community and a lot of other market players. What is happening? What are they doing? What kind of priority list do they have? What are the timelines?

And then of course, when we see that, when we get to know that, then we need to know which steps to take to contribute to a good IPv6 development and adoption.

We don’t have so many tools actually in the government, to be honest. We have a few very strong tools, and one of the tools of course is legislation, and now I’m talking overall development, whatsoever. I don’t think legislation is always the smartest or the best tool to use to try and contribute to a good, positive development. I think there are many other things we can do to start with. The first step of course is to make sure equipment we buy is going to be compatible with IPv6. We are a big customer by being a knowledgeable customer and doing good procurement, we could actually push forward a lot of development, especially if you gather together and have strategies together with the municipalities.

That’s one very important thing, but the next one is like, “yeah, well when do we start to switch on?” Which services are actually the first ones to switch on it might not even be public services that are the first, urgent services that need to use IPv6. We don’t know that yet, so that’s why the dialogue is so important so we know what to do with our tax money, actually, so we don’t do stupid things. But on the other hand, we need to do something, we know that.

My colleagues are actually using IPv6 without noticing it.

When we started there was no IPv6 in Europe, or hardly any, so we had to tunnel to UUNet in the UK and that was it. These days just about any exchange point in the world is IPv6 capable, if you look at the DECIX in Frankfurt, for example, around one third of the ISPs have IPv6 now.

In about every country in Europe there will be ISPs, smaller ISPs, that do IPv6 today. So there is local expertise. Go to your peers, ask them about IPv6, ask them what sort of products they use, what sort of experiences they had.

And maybe pay them for some consulting, but there is local expertise and you just need to share with your colleagues.

There is a big advantage in IPv6, and it’s the whole subnet size calculation. In IPv4, experience shows that whatever size you pick for a subnet, it’s either too small or too big. In IPv6 you just put a /64 on it and that will be enough for ever and this really saves on address space management, address space planning, network planning and all the overhead that everybody takes for granted that really shouldn’t be necessary. If you ever tell that to a customer: “I’m not giving you what you are asking for”, the customer would be unhappy and that’s a bad way to start a business relation.

In IPv6, the customer asks for a block and you give them a block. And the block will be bigger than whatever he needs. One of the arguments that is made by people that think we are doing it all wrong with IPv6 is you have not learned from the past. You’re giving out big chunks of addresses again. You’re making the same mistakes and IPv6 will run out. What these people just don’t do is the proper math behind it.

What we are currently giving to providers are /32s. We have four billion /32s. There is no way there will ever be four billion ISPs in the world.

IPv4 is good enough, as long as people can get to whatever they want, like, get to Google, get to Youtube, with IPv4, they have no pressing need to go to IPv6.

They will start caring about technology if IPv4 breaks for them. Basically, that is too late, so the providers should be ready before that, before IPv4 actually runs out.

I would be happy if we got rid of this legacy IP stuff. IPv4, this is just legacy from the last century. It is not like IPv6 is solving world hunger or anything, but it’s solving a very critical problem in IPv4, and that’s the address space.

Given that the address space is so tight, IPv4 brings up other problems.

If this problem gets resolved, we will immediately, full-speed go onto IPv6 deployment.

We are, I’d say, a medium sized telco based in the Middle East. We have looked at IPv6, we’ve spent a lot of time evaluating what we want to do in terms of our network.

For transit, for IP transit, there are limitations to the number of suppliers available in the Middle East. Access to the suppliers is also limited and the majority of the suppliers do not support IPv6. Luckily for us though, we run a lot of submarine cable ourselves, and we could get transit from either our node in London or our node in Hong Kong. So technically speaking, it is not that big a deal. But it is a concern.

Looking at the network and what’s ready and what’s not, if I was to dissect the network into parts and say ‘this is a part, this is a part, this is a part’, there are more parts that are ready to support IPv6 than not. The problem is not how many parts are ready to support IPv6, the problem is the extent of those parts. The investment necessary for every single part that is ready for supporting IPv6 is tiny compared to the investment in the access network, and that’s the part that’s not ready. So it’s the access network and the limitations of available equipment in the access network to support IPv6 is the problem we are facing today.

We are actually working with our main access network supplier now to put IPv6 compatibility, or IPv6 native actually, into their equipment. It’s, again, taking time because most of those companies are more interested in the business they can get now than the business they can get in the future.

It’s not fast enough for us – we would rather it was ready now. The time horizon for exhaustion is, say, three years, maybe, if we’re lucky, so really, we’re at that critical stage where we have to drive our vendors harder than ever to implement the support, or else… And we have looked at alternatives, but sadly we can’t find a vendor to support every layer in our access network deployments.

I think it’s time to say, ‘Look, you want to be a vendor, you support it. If you don’t support it and someone else does, we’re moving!’

I’m Technology Program Manager for ISOC, working in the Standards and Technology department. We are simply interested in the health of the network and the best outcome for the End Users. We can provide neutral spaces for the community to come together, whether that’s network operators talking to each other or network operators talking with content providers. Our connections between both the technology industry, the standards experts, the technology experts in the IETF, and our links into the wider user community and the public policy realms gives us a sort of bridging role to play there as well I think, because a lot of the technology community talk amongst themselves and don’t get out to those other areas. We can create a space for those conversations to happen, where they otherwise perhaps wouldn’t, and I think that’s particularly important for IPv6 deployment because a lot of it is about building confidence, and so that’s really what we’re trying to do very much at the moment in ISOC with our programs on IPv6 deployment.

There’s a number of aspects to that, the role of governments and regulators in IPv6 deployment. I think, like all content providers, governments have a responsibility to make their content available over IPv6, and perhaps a stronger responsibility than most content providers, because those services have to be available to their full citizenry, and so IPv6 is going to be a key component in that. And governments also have a role to play in raising awareness of IPv6 and the importance of that for their industry, for their economy and the health of their network. I think, as to whether there is a role for them to go beyond that, it’s debatable; governments and regulators are very reluctant to choose winners when it comes to technology change, and I think that there’s a lot of history there with regards to other technologies, and sometimes you might get it right, and sometimes you might get it wrong, and I think at the end of the day, they’re not necessarily the technology experts and it’s perhaps better left to the market ultimately for the technology deployment to happen. But having said that, there is a role for them to play in raising awareness of the issue and making their services available over IPv6.

I think for many years we’ve heard about specialist equipment like load balancers or firewall appliances not having IPv6 support, or having very patchy IPv6 support, and that has been true, but the technical hurdles to IPv6 deployment are now almost non-existent. The main outstanding challenge is one of education, I think, raising awareness. Network operators need to educate their engineers, educate their network architects. Potential problems on the horizon would stem from widespread industry inactivity until there is no more IPv4 address space available. So something that I, and many others say quite often when we’re talking about IPv6 deployment is that it doesn’t need to be expensive and it doesn’t need to be like Y2K if you start now, take your time, take a measured approach and plan it out. If you leave it till the last minute, it potentially will be very expensive, but that’s precisely why we’re cheerleading for IPv6 deployment now, rather than later.

If you’re not running IPv6, in the end you will only sell connectivity to a part of the Internet, which kind of contradicts the name XS4ALL.

We run a modest scale DSL network with about 300,000 customers in it, and the main thing there is the CPE. Our current modem vendor showed up at CEBIT running a press release shouting that they were IPv6 capable and we invited them over to show that it was a real claim and not only a press release.

One of the main issues involved is firewalling. Since there’s no NAT involved we want a decent firewall which is actually configurable, since people are actually getting a lot of addresses, more and more people will start to run services, so more and more people will actually be able to have incoming connections to their boxes.

Reverse DNS is one of our challenges. Obviously we can’t populate a /48 per customer.

One of the earlier things we decided was, ‘it’s nice, we’ve got so much addresses, let’s incorporate for our server network, lets incorporate the VLAN number into your address space’. And then all of a sudden you’ve now realised that that wasn’t the smart thing to do. You basically have to kill your darlings, throw them away and re-design it from scratch.

One of the things that we ran into is that there isn’t a definitive spec on how DSL modems should behave in an IPv6 environment, and one of the things we did was actually write our own specification now, so that we can actually have one steady document, and we tried to refer it as much to the IETF as we could get it, but in the end it’s our own specification document which we can actually hand out to a vendor, saying, if you want to provide an IPv6 capable modem to XS4ALL, this is the way we expect it to work.

Getting the publicity got some stuff done. We got useful feedback from other modem vendors, our own vendor got quite some feedback and actually realised that they are the first ones who have a working implementation. And our taking it up more seriously, because also for them it’s proved that there is a market for it.

We spent a lot of time basically trying to talk to the technical guys and the CTOs and stuff, and in the end it took off because sales got interested. So it nicely fits in our brand and the way we want our people to look at our company, and on the other hand I do realise that somewhere in the near future they have to do it anyway, and it’s better to do it in your own tempo than all of a sudden being confronted with that little ’sold out’ sign, and you have to force things within maybe months to go IPv6.

If you’re getting connectivity in a data center, as a transit over an international connection, as a cross connect inside a telecom hotel, if you are an enterprise, IPv6 should just be a tick mark.

Around 2001 was when Hurricane Electric first started to look at IPv6 and say, ‘how do we even get our feet wet?’ The experience of doing something new, in this case IPv6, always has a plus, but finding the value, finding where the customers come from, was a very slow process. But from 2006 through 2007, 2008 and now 2009, the growth of IPv6 on our network has been enormous, and it has been not only because of the right base, but also because of the fact that we had a commitment. The key part was that the business case was starting to make sense over all those years. The business case for us was that we still wanted to be in business when we saw IPv4 depletion as being real.

We saw customers coming to us because they had an IPv6 requirement. They were looking for IPv6 providers, they chose us, so we see revenue coming in directly because of customers looking for IPv6 capabilities. We also have customers that come to us and say ‘oh, you do that IPv6 thing? What is that? And should we know something about it?’ We talk about the reasons why you should look at having IPv6 in your network, why you’re doing future protection, why, if you’re a content company, you may have a consumer base in a couple of years time that may only be able to access you over IPv6. And those companies come back and say, ‘ok, we’ll add that to our engineering roadmap’. So that is not the primary reason they came to us, but hopefully somewhere they go, ‘huh, good thing we came to a provider that actually understood where the future was going’.

If we were going to be in any way successful, we had to make sure that everybody from the front desk through the accounting department, and definitely through the sales department, understood what IPv6 was. So we made probably three very conscientious decisions: first conscientious decision was that everybody in the company had to understand what IPv6 was. Second part was that we needed to make sure that our customers understood that when they phoned in for support, they weren’t asking a special question; if you phoned into the NOC and said, ‘I have a v6 issue, I have a v6 question’, the person would respond with saying, ‘yes, how can I help you?’, as opposed to, ‘oooh, you want to talk to Joe, v6, yeah, that’s Joe’s department. He’s not here til Thursday.’ That was not what we wanted to do. We wanted to take that decision and get ahead of the curve.

The third thing we did was, we said let’s take this out of the company. And that’s what created the IPv6 Certification Program, which is on Hurricane Electric’s website. That type of outreach to the community and help with them, has not only had benefits from a marketing point of view, but has also clearly brought a lot more people to the table for IPv6, wherever they are in the world.

One of the things that we have talked to prospective customers, and have seen as great success, has been to talk to the engineering staff, business development staff, whichever the right group is that’s pushing the IPv6 initiative, and say ‘take one step at a time, and far more importantly, take at least one step into the v6 world, even if it’s in your test lab, even if it’s only in a tiny part of your network, and get some familiarity’. And it turns out that once you take the first step, you sort of start realising that parity between IPv4 and IPv6. Things are pretty consistent: you do this in IPv4, you do the equivalent in IPv6. If you’re doing security and filtering in IPv4, you do security and filtering in IPv6 – why wouldn’t you? If you’re doing address management in IPv4, you do address management in IPv6. That has been very useful to people: to realise that maybe getting a little bit of IPv6 in the network before re-thinking the whole problem, it makes life a little easier.

When we look at planning for IPv6, we plan for it in the same way we plan IPv4. So let’s go through some of the things that Hurricane Electric did. DNS services to all our customers, and to the external world: that was one of the easiest things to do in the IPv6 world. Email: email took a little bit of time. Only recently have you started to see the appropriate tools working for carrier-based or ISP-based email systems to support IPv6. One of our interesting hiccups was NTP, the Network Time Protocol. So we took a step back, went back to the open source solutions, which had been fairly well tested, but that was a step back to us, and now we’re pushing for that to come out again, commercial-grade IPv6. Everything else, the stories of Internet routers and core backbone routers throughout the eight years that we’ve been playing with, the history is an interesting story, but the reality is anything shipped in the last three, four years is pretty much IPv6 capable. There are very few exceptions at the core of the network. Firewall vendors and load balancers are now finally, this year, starting to come out with the appropriate hardware, so those parts of the network are now coming back in line with the commercial-grade requirements that we have. Finally, the desktops: well, guess what? Your desktop network is ready for IPv6 today! It’s done. There are definitely a few applications that still need porting, but pretty much, desktop-wise, that’s an easy task as well. So what’s left to do? The customers. Just telling them our story, other people telling them the right story. The network is ready!

It’s another way of reaching Google services, and if we can serve our users better over IPv6 than we can over IPv4, then we will do it.

We think that the demand for IP addresses will be in large user networks and we are committed to good user experiences, and IPv6 will give us that when IPv4 addresses run out, so the first goal is to get IPv6 working on the front-end so that the users can connect to it.

The most important step in some way was the first step of launching a public service that was available over IPv6. And that was the day in March that we launched ipv6.google.com. Because the first service launch you don’t know how much traffic there’s going to be, there’s no precedent for it, you’re starting something new and you don’t necessarily know how it’s going to go. And after that, a service already existed, and it was only a question of scaling it up. At the moment, www.google.com is only available to users of our Google Over IPv6 program, over IPv6. As regards everybody in the world being able to connect to www.google.com over IPv6, the issue is that we know that certain networks and certain devices that are in the network at the moment fail in the presence of IPv6, they fail, so it’s usually closed to users that don’t necessarily know how to fix it. The user won’t know that his ADSL modem is dropping his IPv6 packets and black-holing, he will just see that Google is slow or that the Internet is slow. So that’s why we have to be cautious, because the broken-ness damages the people that are not able to fix it easily. But at the moment we’re catering to early adopters, and trying to gain operational and trying to help other people gain operational experience by doing Google Over IPv6.

Most of them say that nobody notices, which is of course the goal here. We want it to be seamless and transparent, and if it works properly, that’s the way it is. Some of them have said that their performance is slightly better, especially in the case where their production IPv4 links are congested and they can use parallel infrastructure or new infrastructure to do IPv6. Some of them have said, ‘thank you, now that you provide a large volume of traffic and a place to go, and users will notice immediately if there’s some small connectivity problem in our IPv6 network and it will get fixed’. So the feedback has been very positive – no on has ever asked to be removed from the white list, nobody has ever asked for Google Over IPv6 to be disabled for them.

The real impetus came when there was traction internally to deploy a pilot network that was something that developers could actually use. And when developers saw that there was a network, then the coding effort really started. We basically went from zero to being able to serve most Google services over IPv6 to users that had good connectivity in a year and a half. So lots of progress can be made because it’s not a huge undertaking. It’s something that requires a lot of pieces in a lot of different places in the infrastructure to come together, but it can be done with not too many resources in a reasonably short time.

Every time I designed something that looked different somehow between the IPv4 and IPv6 versions, that turned out to have problems in the end. The best way to proceed in general, or at least as far as I’ve seen, is to run everything on the same infrastructure. That way it scales by itself, it’s maintained by the usual people that maintain everything. If it’s similar to the existing infrastructure, your NOC personnel will not have to be extensively trained because they’ll just look at the configuration, they will look at the devices, and they will know what to do by themselves. When you have the ability to do the work yourself, and do it on a volunteer basis, it’s really much easier, so that’s why I say to other companies, other network operators that are attempting to implement IPv6, one of the best things that you can do is tap the enthusiasm that no doubt exists within your company. Look at the people who might be willing to do this, who might be excited about doing IPv6 and just let them do their thing and they’ll surprise you.

If there was such a big problem with IPv6, we should have dropped it earlier. And we haven’t. In 2002, we had a customer come to us to ask if we could provide them with IPv6 services. Back then, very few of us in the company, knew even what IPv6 was. And there was quite a steep learning curve for us.

We drew out exactly how we were going to assign it to customers. We marked out the first /35 for ourselves. We gave the next /35 to our customer as promised. And then we reserved the rest of it, thinking we wouldn’t have to use it for some time. It has worked quite well for us. Our general addressing plan; how we would address and make assignments to End Users was to give every user that needed a single address a /64. And anyone that wanted more than that would get a /48. Moving forward, I think a /56 probably is more appropriate.

We dual stack everything as much as possible. We run quite a large shared web hosting platform. That has sort of a load balancer network in front of it. And the load balancers understand IPv6 and have IPv6 support. The problems that were inherent in interoperating IPv4 and IPv6 networks came out. So, we started documenting all of those problems and building up an internal knowledge base of exactly how to deal with End User problems as they come in. We had a big drive internally to put IPv6 on as many of our important production services as we possibly could and if there was a piece of network hardware involved and the vendor didn’t support it, well we hassled the vendor as much as possible and if that didn’t get us anywhere we simply replaced it. If you make IPv6 support part of your RFI, as such that when this write off period expires you then go to buy new equipment, it shouldn’t be a problem. If we talk about it in this day and age, in 2009, people running network hardware that doesn’t have support for IPv6 routing, at least IPv6 routing then that’s an issue that needs to be addressed in the procurement process.

We decided we wouldn’t use tunnels internally. We decided that we’d natively route IPv6 in the network. And as a result of which, we had complications when it came to MPLS. There is no way of signaling label switched paths using IPv6 transport addresses. Simply translated, that means that IPv6 can only be transported over IPv4 LSPs if you wish to use MPLS. And this is a bit of a problem for us, since no LDP with native IPv6 transport exists. If we didn’t deploy 6PE and use routed IPv6, it meant that we could then go and spend our time doing the work, numbering if you like the core network without having to rely on the IPv4 LSPs. But yes, if I could go back I would have put in 6PE at the same time. And now, for customers that want IPv6 VPNs, they can have it, it just wouldn’t use 6PE.

I think with IPv6 it’s really going back to end user education. When people see an IPv6 address, they gulp. People see an IPv6 PTR record, it looks even worse. People that work with IPv4 for a long time, have these basic instincts. And that doesn’t happen with IPv6, cause we haven’t been working with it for as long and the engineers haven’t been working with it for as long.

Not so many actual technical problems, more sort of training and user acceptance really. And I think training is a big issue and I think operating system vendors as well could do a lot to make that process easier.

Take the plunge. Make sure that you use it first and get kind of an understanding. I mean, it’s one thing understanding how it works, it’s another thing having to use it every day. Make sure you use it, make sure your staff use it. Take the plunge.

I’m employed by Cisco, but I’m speaking here as an advisor to the Swedish government, and the Swedish government, just like many other governments, have been looking at various ways of getting IPv6 deployed. From a government perspective, we have seen various models for governments to try to get more effective addressing, regardless of what protocol it is. A government have different tools they can use: they can just subsidise, and give away money to the market, and they can also of course legislate, but then they can also be a procurer. Well, and then you have of course, also government just making statements, because you should not underestimate the power of someone just making a statement.

So you have these four tools, and given how fast the Internet and telecommunications is evolving, we have seen that subsidy is one thing, of course, that has been very effective, but the problem for a government is then to stop the subsidy – what then happens?

To a certain degree it’s better to give money for people to turn off things than turn on things, because if you give money for people to turn off things, at one day everything is turned off and you don’t have to pay more. If you pay people to turn on things, more and more people will turn on things and you just have to pay more and more and more, until you say stop, and what then happens?

So subsidy for turning on IPv6 is problematic, legislation is pretty slow, but a much, much faster tool, and we’ve seen that in the United States regarding IPv6: being a procurer is extremely effective, because if the government, which actually is a very big buyer of services and goods, if they say, “we require this or else we will not buy your product”, people are very often lining up and changing according to what the government wants. Of course, that requires that the government really writes correct RFPs, high quality RFPs, and that’s one of the areas where some governments do understand the need to work more together with the Internet community and the private sector and civil society, to make sure that the RFPs include the right stuff. Because if the government, on the other hand, just because procurement is so powerful, if they require the wrong things, it can go really wrong!

So, if the government is a provider of services, it’s very important for the government that anyone can access their services, just like any private company is interested in having as many customers as possible, or Internet users be able to access their services. And for example, the Swedish government has very explicitly said that they have as a goal that anyone should be able to access any service from anywhere. So what the government, of course, is nervous about is that if it is the case that a lot of people are, for example, filing their taxes online, the day when the first consumer or citizen or person or entity that is to file their taxes only have an IPv6 address, they must still be able to file their taxes. So at that point in time, which might be some time from now in the future, but that point in time, all the services that a government provides must be available over IPv6.

We need an Internet from the next generation, we need more technology, better technology, better possibilities to work with Internet. This is the reason why we planned, in a political way, IPv6.

We have the task to organise the DE .government as a LIR (Local Internet Registry), we want to build one infrastructure for the counties, and for the whole of Germany, that counties and municipalities can dock on with their own infrastructure, and this is called “Couple Nets for Germany”. And then we planned a network for our ministries and federal communication infrastructure.

I think in government we have to plan for the next 10-20 years, and our aim is to structure, or have a good structure and a good hierarchy of routing for the next years. I think it’s necessary to talk about our plans as a government, and to give a sign for providers and vendors that we are planning to use and to enable our networks.

We spend a lot of money in this market, so the vendors get the sign from us to be there and to offer products in the sector and to offer services, and sometimes new ideas. We have some good products, we have some good ideas and projects and we have good people, and we have new technologies. We want to be on time and we want to be modern, and so we need the vendors, they offer the new technologies.

First we started with external experts, and then we have internal experts from our agency of security. We need the community, the RIPE community, and we want to offer our experiences, and we need the help from other countries, from Denmark or Sweden, we need the help from the community to point out these needs and the needs for governments, the special needs: long term planning times and security, we have to open our eyes to see where is the knowledge and the needs and the experiences, I think.

We really think, that everybody else should not test and deploy IPv6. It’ll be great for us.

We started in the mid 90s. We had a parallel network, based on the KAME stack in BSD that was running IPv6; so we could supply IPv6 to a customer and IPv4. But they came over separate wires; dual stack didn’t exist. Every time that two transports or two layers have not been congruent it’s been deadly in the NOC with debugging. If you and I want to experiment with a new protocol, we just install it on our two computers and the Internet doesn’t have to change. If we put all the smarts in the middle and if we have to put a bunch of NATs and carrier grade NATs in the middle of the network that kills that.

The actual problems in deploying today. There’s some key problems:

- Customer Premises Equipment (CPE)
- For the content people: Load balancers
- Intrusion Detection Systems and security products; checkpoint etc. – very poor, very poor.

And what the user wants (don’t give them a list of features!) is parity with IPv4. All the things I use in IPv4, I want in IPv6. It’s what’s been called the chicken and the egg problem because the customer doesn’t want it. They’re never going to want it. They want the results, they don’t care how they’re delivered. That’s my problem, not their problem. They just want their MTV, and their email and their DNS, and whatever it is.

And the problem is, because it doesn’t make sense economically right now. The IPv6 backbones are poorly interconnected, there’s a bunch of tunneling, there’s a bunch of MTU problems. As I said, there are these blockers at the vendors. Because there’s not real money there, there’s no real economic social pressure to fix those things.

As we hit the IPv4 wall, that economic pressure will be there. Three years from now when they can’t get IPv4 space there are going to be two kinds of players in the game. Those that have IPv6 experience, and paid for it incrementally and they’re just going to keep going like this. And there are going to be those who had no IPv6 experience and didn’t prepare and their dollar curve or Euro curve or Yen curve is going to be like this. Their learning curve is going to be like this. The vendors who did not do early IPv6 development are going to say, “We’ll give you a product in a year or two,” while the vendors who did say “Now”, and you know who is going to survive, it’s what’s called present value.

So, three years out, you are going to have this cost. What’s the present value of reducing that cost by 50%? And what you’re willing to spend now, to do that. And I think it’s worth it.

Our enterprise customers, which are a big customer base, they have dual stack. It’s not even a question we ask. We’re putting NAT-PT equivalent in those little boxes so those people can run a pure IPv6 network if they want, not even dual stack and still get to the IPv4 Internet. So, people should go out and do their front end. Just put a little makeup on your face, you don’t have to change your life. Fix your DNS, make it dual stack. Take your mail server, make it dual stack. Take your web server, make it dual stack. For two reasons: you gain experience and secondly, what faces the world is dual stack, and that will increase the economic pressure that’s going to get the kinks out of the system, to have enough experience to say “ok, I can’t get senior management to buy off on what I need for the transition. I at least know what I’m going to need for the transition.”

If you start now, you have a reasonable planning horizon. You’re talking years. If you don’t start now and you wait three years, you’re not going to have a reasonable planning horizon. There’s toolset parity essentially between IPv4 and IPv6. So what you’re used to, you’re not really going to have to learn a lot more. As Gaurab Upadhaya said: “96 more bits, no magic.” But we need these these 96 more bits, desperately. Desperately!

Get the experience. Get the experience. Otherwise, you are going to be blindfolded when you walk into the wall!

It’s about just rolling it out piece by piece. Start at the edge, and work in.

We started looking at IPv6 for ourselves fairly recently but we’ve rolled them out onto some customer networks over the course of the last two or three years. Our own deployment happened about three months ago and we’ve had a policy to dual stack every new service that we roll out onto our own network since that deployment on our edge.

During our own implementation we haven’t actually run into any bugs and I believe that’s thanks to the work of the community for the previous ten or fifteen years. We find that it’s actually quite stable and reliable. A number of other networks have said that particular equipment had bugs with regards to addresses no longer responding for example, but vendors in our experience are taking this seriously because they want to run consistently reliable IPv4 and IPv6 addressing products.

We have customers with specific load balancers and firewalls that they selected that have a particular feature that they need so they are tied to that vendor and that vendor is maybe moving slowly or they maybe want to end-of-life the product or something along those lines. We’re finding that sometimes a customers’ hands are tied because they’re required to use a feature that isn’t in the softwares that they use.

I think that now it’s possible to just switch it on for people, whereas before you were maybe running beta or engineering code if you wanted an IPv6 feature, whereas today it’s production ready in a bunch of kit that isn’t expensive and is well documented. So if you want to do an IPv6 rollout it’s possible to just read around the subject widely, and plan a rollout.

It’s easy to monitor IPv4 and IPv6 and it’s also necessary to monitor IPv4 and IPv6 because the way the Internet edges are configured you can have a different topology of how you see your peers over IPv4 and how you see them over IPv6.

The cost of rolling out IPv6 wasn’t huge to us because we’d already selected kit when we bought it that we would be able to do IPv6 in the future. So, we look for IPv6 support in our routers and we run Linux on our servers, which has been IPv6 capable for a long time. So we didn’t find that we had to go out and buy anything new. The service providers that we partner with for connectivity, we told them we wanted to do IPv6 and most of them were actually ready to roll out service.

If you look for reasons to make the IPv6 rollout complicated it’s going to go wrong. You should just roll out IPv6 support at your edge through to your core, in a simple process. A light touch so that you’ve got IPv6 routing possible first and then maybe IPv6 DNS and then maybe some of your NOC services so your staff are trained, and then maybe your mail services, so you can monitor them service by service and just prove that the IPv6 rollout has been a success.

There are going to be some options to extend the life of IPv4 but are they going to be as good as rolling out IPv6? I don’t believe so. I think that IPv6 enables us to preserve the end-to-end principle as much as possible which is the reason for innovation on the Internet. It’s fine for IPv6 to just be an addressing format because the only problem we are trying to solve is running out of addresses. Feature compatibility with IPv4 means that it’s easy to understand and easy to roll out and there are fewer new things to learn.

Read around the subject widely, realize it’s not very difficult, don’t make it complicated and roll it out today.

Question: What are the benefits of IPv6?

Daniel: It’s more addresses. There are no other benefits to IPv6, but more addresses can be very crucial if you want to grow. I think what I would say to businesses, and what I’m saying to business for years already is to be aware that IPv6 is coming, to be aware that IPv4 is running out, first and foremost, and to avoid the crunch. There are projections on when no unallocated IPv4 addresses will be available. You make your own judgment. And be aware that when you deploy in a hurry, it’s going to be more expensive, and even worse, if you have to deploy in a hurry, it might limit your growth. So what you should be doing is consider what does it cost your business if you cannot grow in the way that you’re used to growing right now.

Question: Why has IPv6 adoption been so slow?

Daniel: It’s basically because the benefits haven’t manifested themselves. IPv6 is only about more addresses. As long as there are enough IPv4 addresses for people to deploy their networks, there’s no incentive to deploy IPv6, other than the incentive to be first or to learn about it.

Question: What are the Regional Internet Registries (RIRs), including the RIPE NCC, doing to promote adoption of IPv6?

Daniel: I think the RIRs are doing what they can and what they need to do. I don’t think the RIRs should have a role of pushing it. I wouldn’t be comfortable with the NCC to actually see, or to be very pushy about this and try to make these decisions that actually businesses should make themselves.

Question: What is your advice to the Internet industry?

Daniel: First of all create awareness of the problem. Make sure that both the operational part and the management knows about this – small investments now will make all the difference in the future. Create knowledge in your procurements, especially in your equipment, make sure that you do not block the way to IPv6, by actually having to re-invest, and try to build the knowledge in the organisation, and monitor the situation, monitor your growth, I mean you do that anyway, and make a judgment about when the scarcity of IPv4 addresses will quench your growth in the future. Look ahead!

Question: What do you see as the future for IPv6?

Daniel: Well obviously I think the quality of v6 networks will improve. The more production use gets made, real users will use IPv6, the more the incentive will be there to operate the v6 networks to carrier grade standards. Operating them is not rocket science, it’s just a matter of getting it out of the development and trial sphere into the production sphere, and I’m seeing signs of that, so I’m confident that that will happen.