Deploy360 IPv6

NAT64check proves popular

We’ve already mentioned this a few times this year, but we’ve just published an more in-depth article about NAT64check over on the RIPE Labs and APNIC websites.

NAT64check is a tool developed by the Internet Society, Go6, SJM Steffann and Simply Understand that allows you to enter the URL of a particular website, and then run tests over IPv4, IPv6 and NAT64 in order to check whether the website is actually reachable in each case, whether identical web pages are returned, and whether all the resources such as images, stylesheets and scripts load correctly. The rationale behind NAT64check is also explained, how it works, and how you can use it.

If you just want to take a look at the tool, then please go to either or, type the URL you wish to check into the box at the top of the page, and the result should be returned within a few seconds. It’s simple and easy, and will help you identify what needs to be done to make your website accessible with IPv6.

Deploy360 also want to help you deploy IPv6, so please take a look at our Start Here page to learn more.


Deploy360 IPv6 Tutorials

‘Introduction to IPv6’ Online Tutorial Now Available!

IPv6-imageThe Internet Society has developed an online tutorial called “Introduction to IPv6” to provide a brief primer for individuals who are interested in better understanding IPv6.

The target audiences for this tutorial are recent university graduates, network administrators, network engineers, and other parties with a working knowledge of IPv4 who are looking for a basic course on IPv6. The course consists of the following modules:

  • Introduction to IPv6
  • Understanding IPv6 Addresses
  • Protocol, Neighbor Discovery, and SLAAC

As IPv4 exhaustion becomes more and more imminent, network operators across the globe are taking a closer look at transitioning to IPv6. Given that the Internet is now a critical global infrastructure for socio-economic growth and is growing faster in developing countries, there are a number of key drivers for IPv6 migration to be accelerated in these nations. A number of these drivers are highlighted below:

  1. Many developing countries have made considerable strides in ICT but still trail developed nations as it pertains to Internet access. This ‘digital divide’ can be reduced by extending wireless networking and mobility through the provisioning of a larger address space via IPv6.
  1. By expediting the migration of IPv6, governments can deliver enhanced support for public safety networks, as well as reduce the complexity associated with the management of such. These broadband networks better allow emergency services, such as police, fire and emergency medical services, to respond to a wide array of natural, man-made and emerging threats.
  1. IPv6 is the ideal platform on which m-Health capabilities can be built. M-Health applications include the application of mobile devices in gathering clinical data, conveyance of health-related data to medical practitioners, researchers, and patients, real-time patient monitoring systems, and remote home care by means of mobile telemedicine.
  1. The underlying protocol for smart grid technology is preferably IPv6. Smart grid computing provides monitoring, analysis, control, increased cyber-security and communication capabilities to electrical delivery systems in order to maximize the throughput of the system while reducing the energy consumption.
  1. Mobile banking and mobile payments can substantially improve access to banking products ­ such as savings, deposits and insurance ­ for lower income demographics. These services provide ways and means for the unbanked and underbanked persons to invest in productive assets, expand their businesses and protect their livelihoods. IPv6 is emerging as the preferred platform and is a core component of the wireless Internet architecture (2G, 3G, 4G and beyond).

You can access the “Introduction to IPv6” tutorial on the Internet Society website at:

The tutorial is also available in Spanish.

Check it out and give us your feedback!

Deploy360 Domain Name System Security Extensions (DNSSEC)

What We Learned: DNSSEC KSK Rollovers in go6lab

The short story: A KSK rollover on the OpenDNSSEC platform is easy and you should not be scared of it.

The longer story: A little over a year ago, we decided in the Go6lab to start learning DNSSEC by doing it, so we set up OpenDNSSEC for signing domains and followed this excellent deployment document, written for us by Matthijs Mekking. Our domains were signed and DS records published – both “normal” domains like,,  and also reverse domains, like and During the process we found some bugs in the software and in the document, and since then all of them have been fixed.

A year passed and we decided to do a KSK rollover for all signed domains, as it’s advisable for security reasons. To be honest, this was one of the steps in the whole DNSSEC signing process that worried us most, as it’s not a secret that some people mess up the process in this part of the DNSSEC maintenance sequence. Matthijs promised to write another deployment-oriented document for KSK rollovers – and one day in August the first document draft was in our mailbox.

After reading it, we sent some comments on what would be the bare minimum of information that needs to be added (or removed) to understand the process and what’s going on to the point that we can do a KSK rollover and not cause our domains to disappear from the Internet. We believe that the final version of the document is now exactly what you need to know, if you want to do the KSK rollover on OpenDNSSEC and not read more than three pages of documentation 🙂

So, what does the KSK rollover process look like? A misunderstanding of the documentation lead to a quick fix, so after the first domain all the others were done as described in the document mentioned above.

When you decide to do a KSK rollover, you check your keys in the OpenDNSSEC repository and if there are new KSK keys with status “ready”, you export them, get the DS (or DNSKEY) information, replace the DS set with the new one at the parent DNS and wait until you can see the new DS set being served from your parent DNS server. Of course, for .si zones we submitted the DS keys to our .si TLD and for reverse zones we changed the DS information in the RIPE domain database objects.

Not to panic – when your signing platform automatically creates a new KSK key, your domain will not “fall off the Internet” or become unreachable. The KSK key doesn’t expire and rollover is your administrative choice. If you decide to do nothing, the old key will stay there and still protect your domain. It’s good advice, though, to change the KSK key every year just to make sure that nobody can try to break your KSK key over a longer period of time.

OpenDNSSEC creates a new KSK key automatically for you a year after signing. When you see new information being active you issue the ds-seen command on your OpenDNSSEC platform and the system itself will take care of everything for you. When reading the more thorough documentation before I thought that those timers for removing the old KSK keys were exaggerated, but now I’m grateful that they are as they are!

All KSK rollovers went fine, and I was checking the availability and analyzing DNSSEC validity all the time throughout the rollover process with several tools available! You can analyze them too – here’s the example of one of my domains:

So, there is no reason for any concern or fear – KSK rollovers are really easy, once you do it once you’ll just repeat it every year with no questions asked!

A few thoughts arose during the process, though, mainly in terms of how to fully automate this KSK rollover process.

First of all, when OpenDNSSEC rolls over your KSK key and makes it available, we should have implemented and in use the CDS (CDNSKEY) mechanism of communicating our keys to our parent server. This mechanism is described in RFC 7344 and would help a lot in automating the KSK rollovers and making this part of the process less seem less complex and dangerous. We are already discussing this with some people and as soon as the first prototypes come out we’ll test them in our lab and report here.

Next is the DS-SEEN command. OpenDNSSEC knows DNS (as it has this in its name), so what are the impediments to make this part completely automatic? When you export your DS set and replace it at your parent DNS server (through whichever mechanism, CDS, EPP, …) you could instruct your OpenDNSSEC platform, “hey, I changed the DS keys at the parent, can you issue the DNS query every hour and when you see the new DS keys published by the parent server, start the DS-SEEN timers and retirement procedure of the old KSK key?” OpenDNSSEC have all the necessary information about where the parent is and the ability to issue simple DNS queries, compare the answer with its database, and decide when things are ready to proceed.

How hard can it be?

A KSK rollover could be completely automated and we were quite tempted to write a bunch of bash scripts that would do that, but the decision was that this needs to be solved at a system level and not by a bunch of home-brewed scripting tools.

Conclusion: A KSK rollover on OpenDNSSEC is easy and you should not be scared of it, just follow the instructions and don’t forget to analyze the DNSSEC validity during the process. Really.

Deploy360 Domain Name System Security Extensions (DNSSEC)

Are You Protected By DNSSEC? A Quick Way To Check

Want a quick way to check if you have DNSSEC validation working at your site? Just go to:

You’ll see either a thumbs-up or a thumbs-down:

Thumbs Up DNSSEC Tools Thumbs Down

If you get a thumbs-up then all the DNS queries were validated with DNSSEC.  If you get a thumbs-down then your local DNS resolver is either not validating with DNSSEC or is not validating all queries.  Time to figure out what’s wrong!

If you need to configure DNSSEC validation, we recommend SURFnet’s white paper that includes easy steps for common DNS resolvers.

And if you know very little about DNSSEC and want to learn more, please visit our Start Here page to begin!

Deploy360 Domain Name System Security Extensions (DNSSEC)

Video: BIND and DNSSEC – What Is New?

How does BIND work with DNSSEC? How easy is it to configure? What new features does it have that makes DNSSEC signing simple? How does it work as a DNSSEC-validating resolver? To answer these questions, I interviewed Eddy Winstead about BIND and what it can do with DNSSEC. We discussed BIND’s features as well as new training programs and documentation. It was an enjoyable interview that we recorded while Eddy and I were both at ICANN 51 in Los Angeles.  You can read more and download BIND from and more information about DNSSEC can be found from our Start Here page.


Deploy360 Domain Name System Security Extensions (DNSSEC) Tutorials

Case Study: The Experience of Signing Go6.SI with DNSSEC

Some time ago Matthijs Mekking, one of the authors, maintainers and coders for the OpenDNSSEC project asked me why domain was not signed. My answer was that I need a short, precise and deployment/operations-oriented document with clearly described steps on how to setup the signing platform, how to add a zone and sign it.

Matthijs accepted the challenge and soon we got the first draft of the document to Go6lab. There were some errors in the procedure, so together we fixed them. Matthijs added some more information that he saw as needed for better understanding and re-tested the procedure again – and this time it worked. After some cycling through the Linux distributions we found that using Fedora and installing OpenDNSSEC from their repository usually brings you the latest version of the code – and the issue that we found in first round of testing was fixed in new version (the issue was that if you had OpenDNSSEC signer as “bump in a wire” between silent primary and secondaries that served the signed zone – signer did not understand “NOTIFY” message from primary and did not transfer new zone for signing).

opendnssec_logo_120We decided to install OpenDNSSEC signer as “bump in a wire”, fetching the unsigned zones from the “silent” primary server, where we edit and change the zones (with notify to signer), sign the zones on signer server and push them over AXFR to two secondary servers that acts like primary and secondary DNS for that zone. Seems easy – and it is, in a way 🙂

The “silent” primary server runs on PowerDNS with a mysql database backend. The two secondary servers that are serving the signed zones are both running bind9.

At first glance all worked fine, following the deployment guide we added, and zones for signing ( was a test “mule” to see if the process works). The signer got the zones, signed them and pushed them to both name servers and Our .si TLD dnsmaster Benjamin Zwittnig inserted for us DS records in .si zone and the whole thing started to work. We are pressing now our registrar to implement the tool to insert DS records to .si zone without bothering Benjamin.  Hopefully this happens soon.

So, with DS records in parent zone we were able to test the whole thing and all was fine… until I stopped changing the zones and the primary server did not send any NOTIFY to signer server that there is a change in the zone for some time. And that “some time” was exactly the time that was set for a zone to expire. What happened was that signer server realized that the zone expired and instead of asking his primary name server for retransmit (AXFR) – the server expired the zone and stopped serving it.

So, was off-the-Internet for 20 minutes!  When my monitoring system alerted me that there is something wrong with DNS responses for that domain, I immediately figured out that signer expired the domain without refreshing it at the primary server.

As I needed to solve this issue quickly I created cronjob that forces a NOTIFY for all signed domains on hidden primary server every day at midnight – and so domains never expires on signer server. I also reported this bug to Matthijs and I think that the fix will be done in next release of the software.

It’s good to have a real environment where we can test and stress-out these new tools that are making the Internet a safer place – and also make these tools better with finding bugs before they hit somebody else in a big production environment.

You can now download the latest draft of Matthijs’ opendnssec-start-guide document that I used to set up the whole thing. Please note – it’s a draft, so all comments, suggestions and ideas are more than welcome.

screen-capture-278How did we test if our DNSSEC signing was correct and valid? We used three tools:

… but there are many others out there, described at our DNSEC Tools page.

P.S. If you would like to get started with DNSSEC, please visit our Start Here page to find resources tailored for your type of organization or role.

Deploy360 IPv6

PHP Domain Parser Adds Support for IPv6


The PHP community recently announced the release of the initial draft specification for PHP. This is an important step in the development of any open language.

With the announcement they also showed some usage statistics for PHP, and called PHP the lingua-franca of the Internet. I’m not sure if PHP is the common tongue of every programmer who creates web pages, but it sure is popular. Just look at these usage statistics.

With that many users we get excited when an important PHP library gets IPv6 support. The php-domain-parser from Jeremy Kendall just implemented IPv6 and International Domain Name(IDN) support in its 1.4.0 release. This means that the library will now correctly parse IPv6 addresses, and unicode domain names.

The php-domain-parser is available on Github.

If you would like to get started with IPv6, please visit our IPv6 resources or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have an IPv6 case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!

Deploy360 Securing Border Gateway Protocol (BGP)

RPKI: How I signed go6lab IP resources (and survived)

Securing BGP

On July 1st I had few minutes of spare time on my hands, so I decided to go through the procedure of Resource Public Key Infrastructure(RPKI) signing go6lab IPv6 and IPv4 PI resources that I received years ago from RIPE-NCC. I had already setup the validation part on a BGP router previously, learned how that works, and how convenient a system like RPKI helps you with your routing decisions.

However, back then there was no easy way to sign your resources if you had PI address space. After some discussion in the community, RIPE-NCC decided to also deploy the system for PI holders.

With the help of RIPE’s Atlas probes I was able to measure the reachability and visibility of my ASN from many nodes across the global Internet. As you’ll see, nothing broke after I signed the resources. The sky did not fall, my AS remained reachable, nothing unexpected happened, and the entire process took me only 4 minutes 🙂

First about the process, if you are a PI holder in the RIPE region, go to the “RPKI for PI holders” page and read what you need for successful signing of your resources. After you make sure you have everything you need, start the wizard to set up Resource Certifiation for PI End User resources.

Here you’ll have to enter your ORG identifier, or prefixes that you would like to create ROAs for. Be sure that your maximum lengths match your announced lengths, or you’ll invalidate your prefixes immediately after publishing the ROAs. You can also press “Suggest ROAs” and see if the suggestion is correct, in my case it was. Then you press “Publish ROAs”, and after about 3 hours, needed for ROAs to propagate, you can go to your RPKI validator. Which you installed if you set up RPKI validation for your BGP router. There you can find your resources and also see what the view from the BGP perspective is. They’ll be either Valid, Invalid or Unknown.

View of signed resources in RIPE Lirportal
View of signed resources in RIPE Lirportal
Validity check on RPKI Validator
Validity check on RPKI Validator

After that you can go and check how your BGP routers see your own resources in their Routing Information Base(RIB) if you set up RPKI validation. Hopefully you get the status “valid”.

I’m always measuring the global reachability and visibility to the go6lab network. Below you can see, excerpted for clarity and simplicity, that nothing really happened in terms of reachability on July 1st.

Atlas measurements from IPv4 Internet towards Go6lab
Atlas measurements from IPv4 Internet towards Go6lab
Atlas measurements from IPv6 Internet towards Go6lab
Atlas measurements from IPv6 Internet towards Go6lab

Those 3 lines of breakage are because the owner of the building where Go6lab is decided to replace the main power switch with a new one. This caused 3 major outages throughout July 3rd that my UPS’s did not manage to cover 🙁

So, operators and netizens, please go and sign your IP resources and setup the RPKI route validation on your routers. If you follow RIPE’s advice and install invalid routes with localpref 90, and not reject the route, this can become a powerful tool to protect us all from route mis-originations. This tool will only be useful if everyone deploys it and starts using it. So please, go and deploy it 🙂

The next step, and possibly a topic for my next post, would be to invalidate ROAs and measure what happens. How many BGP routers on the Internet are rejecting invalid routes as opposed to installing them with a localpref 90? As suggested on RIPE-NCC RPKI resources set-up site.

For more information on Securing BGP visit our Securing BGP start page.

Deploy360 IPv6

Live Demo of 464XLAT at Swiss IPv6 Council Event

Last week, at the Swiss IPv6 Council’s “IPv6 Business Conference” in Zurich, I did a live demo using the 464XLAT mechanism on my Android phone, using it to allow IPv4-only applications like Skype to work in an IPv6-only mobile environment. The process got a bit bumpy, but in the end it was a successful demo!

Let me back up and say that the event, overall, was a great success. I saw some new IPv6 material and perspectives that I had not seen at other meetings, so I am thankful to Silvia Hagen for the invitation. I actually did two presentations in addition to the live demo. My first talk was about the “IPv6 troubleshooting for helpdesks” document and tool, which we’ve talked about here recently. My second talk was about the story behind RIPE-501 and RIPE-554: “IPv6 requirements for ICT equipment” publications, which we talked about here last year.

The third session was one that could have – and nearly did – go completely wrong: a live demo of 464XLAT in an Android phone. You can read more about how 464XLAT works and my first lab tests in the go6lab in this previous 464XLAT post. I would again like to thank Simobil, the Slovenian mobile operator that (long ago) provided me with an IPv6-enabled SIM card for tests and live demos.

Troubleshooting the Demo

Jan explaining 464XLAT

The issues began the day before the meeting when I realized that data roaming in Switzerland adds new unpredictability into the equation. Big thanks to Gert Doering for his assistance as we frantically fiddled with various settings and every possible combination of SIM cards and devices to find the combination that would work. In the end, we realized our major issue was a setting in Simobil’s billing system. When Simobil introduced LTE, they re-provisioned my test SIM card and the script set the roaming limit to 60EUR. When I reached this limit, strange things started to happen: the PDPv6 context was established, I got an IPv6 address, the CLAT interface did not start, and traffic did not move. Simobil quickly removed the limitation the morning of the live demo, and the whole thing started working immediately.

Just before I was set to go on stage, Skype decided not to connect anymore via my tablet. My turn was quickly approaching and I had no time for further debugging. After a brief explanation of the situation, I showed the tablet to the audience – the working connection, the IPv6 address, the 3G connection, the functioning Google and Facebook, the CLAT interface – but from some strange reason, Skype wasn’t working anymore. After some live debugging I decided that maybe the NAT64 server in Simobil’s core had some problems.

Live demo
Video stream of what’s happening on Nexus7 – interfaces and IP addresses (CLAT and others)

I tried to assure the audience that usually this works flawlessly, and went back to my seat to troubleshoot some more. Silvia continued the presentation with some IPv6 use cases and I left the stage, completely frustrated with the outcome of my live demo. I’m an engineer; I judge by results.

From my seat, I opened Skype on my laptop and began chatting with my friend Nejc from Simobil online, who had just helped me with the billing issue. He agreed with my assessment that something was wrong with their NAT64. Then I realized – there’s a working NAT64 in my go6lab (three of them, in fact)! I suggested that he reconfigure the GGSN to send one of my DNS64 addresses when establishing PDPv6 context. I re-established my PDPv6 session, received DNS information pointing to one of the implementations in my go6lab and voila – Skype connects!

Success! The 464XLAT starts, Skype connects, and video call works!

I stood up, interrupted Silvia’s presentation, and loudly proclaimed the issue solved, and called Silvia on Skype, via her mobile phone. We got the video up and showed the audience how the whole setup works. Obviously, the first question from the audience full of engineers like myself was, “How did you make it work and what was wrong?”

I explained the solution of using a different NAT64 server, and the audience was quick to realize that, in fact, everybody using IPv6 on Simobil’s network was now sending traffic to the go6lab. I assured the audience the lab has enough uplink capacity to keep it going until Simobil’s NAT64 translation service returns to operational.

Thanks, again, to Nejc Bačič from Simobil for all the help, and to Silvia Hagen for helping do the live demo with me – and for being flexible enough to let me interrupt the program to finish what we started and show a successful result!

Deploy360 IPv6

Dhcpy6d – A new tool to help with DHCPv6 (DHCP for IPv6)

We received the following guest post from Henri Wahl in the IT Department of the Leibniz-Institut für Festkörper- u.Werkstoffforschung (IFW) in Dresden, Germany.

Getting DHCPv6 to work

dhcpy6dWe run a network with approximately 1.000 client hosts. To use dualstack we decided to provide hosts with IPv6 addresses via DHCPv6. We wanted to use our existing MAC-based IPv4 address provisioning for IPv6 too and SLAAC gives not enough control regarding different classes of clients and dynamic DNS updates. Sadly we found no working solution, especially because RFC 3315 does not consider MAC addresses as useful. Thus we had to develop our own incarnation of a DHCPv6 server.

The result is dhcpy6d, available as open source at and written in Python. It retrieves MAC addresses from local neighbor cache and this way allows us to keep our address management solution for IPv4 and IPv6.

Our DHCPv6 server allows to identify clients by MAC address, DUID or hostname. Clients can be organized in different classes. Addresses can be generated randomly, from MAC address, by range or by a given ID. Clients can get multiple addresses. Leases are stored in MySQL or SQLite databases. DNS information might be updated with ISC Bind9.

In practice we found Windows clients from Vista and up to be working perfectly as DHCPv6 clients. They even have no problems to receive multiple addresses per client. Linux and MacOSX desktop clients still fail on this.

Dhcpy6d still is work in progress but already works flawlessly on a daily basis. There are at least some universities which use it.

For details see .

Deploy360 Domain Name System Security Extensions (DNSSEC)

Fedora 21 To Have DNSSEC Validation Enabled By Default

Fedora logoBy way of a recent tweet from Red Hat’s Paul Wouters we learned the great news that the next release (21) of the Fedora operating system will include a DNSSEC-validating DNS resolver enabled by default.  According the Fedora 21 release schedule, if all goes according to plan Fedora 21 should be generally available in October 2014.  This will mark the first of the major Linux distributions that I am aware of that will offer the added security of DNSSEC validation by default.  With Linux, you can of course always add a DNSSEC-validating DNS name server such as DNSSEC-Trigger, Unbound, dnsmasq or another DNSSEC-validating DNS server, but this move by the Fedora project will have the validation occurring by default.

From the Fedora 21 Proposed System Wide Change message:

There are growing instances of discussions and debates about the need for a  trusted DNSSEC validating local resolver running on There are multiple reasons for having such a resolver, importantly security & usability. Security & protection of user’s privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide.

People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust.

Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. 

Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but be unavoidable. Because it will perform the most important operation of establishing trust between two parties.

All DNS literature strongly recommends it. And amongst all discussions and debates about issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It’ll simplify and facilitate lot of other design decisions and application development in future.

This is great news for those of us who want to see the security of the Internet strengthened through DNSSEC – and definitely in keeping with part of the plan for where we need to see DNSSEC validation.

Kudos to the team at Fedora who are making this happen and we look forward to seeing it come out in Fedora 21 later this year!

Deploy360 IPv6

CloudFlare Enabling IPv6 For All Customers

CloudFlare logoBuried in a post last month about Martin Levy joining CloudFlare was this gem:

CloudFlare is enabling IPv6 by default for ALL of their customers!

If you are not aware of CloudFlare, the are a “content delivery network” (or “content distribution network”… either way it is “CDN”) that takes your website and makes it available through their large network.  A CDN can help you accelerate the speed at which users access your content. They also can help with performance issues, protection from DDoS attacks and many other website concerns.

CDNs also, as I documented in a video a while back, can be an easy path to making your web content available over IPv6.  In my own personal case, I have a couple of sites on a hosting provider that has only IPv4.  Given that I don’t have the time to move them to a hosting provider that provides IPv6, I’ve set both sites up to go through a CDN that automagically makes them available over IPv6.  We maintain a list of CDN providers we are aware of who support IPv6.

But back to CloudFlare…  a few years ago they implemented a setting for “Automatic IPv6”.  All you had to do was toggle that from “Off” to “On” and… ta da… your content would be available over IPv6.  Now, as Martin Levy writes on CloudFlare’s blog:

Many customers have flipped the switch to enable IPv6. That’s good; but it’s time to make the default setting “IPv6 on.” In this day and age this is a very safe thing to do. Over the next few weeks CloudFlare is going to make the default for new customer be “IPv6 on.” No need to flip that switch to be enabled for the whole Internet (that’s IPv4 and IPv6).

In the upcoming weeks CloudFlare will enable IPv6 for existing customers in a staggered release. CloudFlare takes the delivery of each and every bit very serious and you can be assured that every person at the company is involved in making this operation is successful. Yes there will be the option to turn off IPv6; but we strongly believe that at this point there’s little need for that option to be exercised. 

So IPv6 will be on by default for all new customers – and all old customers will be migrated to having that setting enabled.

The results are already being seen in some of the available IPv6 statistics sites.  Eric Vyncke noticed the uptick in his chart of the % of top web sites available over IPv6 and in a posting to the IPv6 group on Facebook attributed that growth to CloudFlare:


Regardless of whether CloudFlare drove that specific growth, the fact is that have a CDN provider enable IPv6 by default for all customers is a great step forward!  Now we just need all the other CDNs to do the same thing and we’ll go a long way toward having a significant amount of the Web’s content available over IPv6.

How about you?  Have you enabled you web content to be available over IPv6 yet?  If not, how can we help you?  Please do check out our IPv6 resources and let us know what other help you need.