Since that blogpost, the European Parliament Plenary narrowly voted on 5th July to reject the proposal tabled by the Legal Affairs (JURI) Committee and a mandate to negotiate, and now the proposed Directive will undergo a full discussion and rescheduled vote in the next Plenary meeting on 12th September. This was a fantastic outcome, thanks in large part to a groundswell of support from those who value the fundamental right of freedom of expression online. It has presented a window of opportunity to correct the deeply flawed approach to copyright reform in Europe and find a more balanced solution. Campaigning has continued throughout the summer period and MEPs are now set to vote again on a proposal that has heavy consequences for the open Internet if passed in its current form.

• Widespread disruption to the webThe Article 13 proposal has an incredibly broad reach in terms of who can be impacted. We face a scenario in which not only the large content sharing platforms, such as Facebook and YouTube, but other businesses involved in storing and giving access to material uploaded by users - music, pictures and videos - will be forced to try and conclude licensing agreements with rights-holders, and could have to resort to content surveillance and removal activities to protect their business. This could include blogging and discussion platforms. This could also potentially impact Cloudflare and its ability to innovate in the European market with new services that offer a storage component.

• Your freedoms and rightsThe proposal threatens the freedom of expression and information and upsets the balance of rights that has been so important to Internet innovation. Creators, users and independent businesses alike - any content that is uploaded may be deleted without your consent by Internet providers anxious not to incur legal liability. The right to freedom to access information and the right to conduct a business are also now at risk.

• User experienceAs the Internet has improved in terms of speed and delivery, the visual Internet buffering experience of yore is now a rarity. Add in a new monitoring and filtering function however, tracking the vast range of content that is uploaded by users against databases of flagged copyright content, and we now have a new layer of complexity which could have a negative impact on user experience. This could range from delays in downloading to vast and confusing blank spaces on the web.

• DiversityStart-ups and smaller businesses will  be heavily burdened by the new obligations, meaning that the internet giants will gain an even deeper foothold in the marketplace. Smaller players will not have the presence, ability or market power to engage in appropriate licensing agreement discussions with the range of rights-holders that exists. Furthermore, in some cases, these arrangements do not even make practical sense.  And so in every sense, diversity in Europe will be diminished, both in terms of providers who can afford to operate in such a market and also the availability of culturally diverse, rich content. Europe will simply lose out, as smaller companies look to other geographic markets and users face restricted choice.

Image courtesy of EDRi

There is still some time left to share your views with MEPs who have a key role in this debate and with those who may have hesitated over the July vote. We particularly appeal to all our European users and readers to contact their MEPs and pass the message that the Article 13 proposal is flawed, upload filters and online monitoring are not the way forward, and fundamental rights must be preserved. You can  check the voting statistics for MEPs in different European countries and contact your local representatives using this website. You can also call your MEP, locating their details using this tool.

As an ardent supporter of the open Internet, Cloudflare has been deeply troubled by the Article 13 proposal and some of the discussions that have taken place. We hope you will join us, and many others, in this important campaign and help to #SaveYourInternet.

Cloudflare is disappointed with the Senate’s actions, as we feel strongly that consumer privacy rights need to be at the forefront of discussions around how personal information is treated. The new regulations would have steered the U.S. closer to the privacy standards enjoyed by citizens in many other developed countries, rather than away from such rights.

Defaulting to an “opt-in” rather than “opt-out” standard would provide consumers with greater controls over how, when, and with whom their personal information is used and shared. We believe that individuals should have the last say on what is done with their personal information, rather than corporations.

Regardless of whether Washington ultimately decides to approve rolling back these regulations, Cloudflare will continue to prioritize the sensitivity and privacy of the data we handle from and on behalf of our customers, and to comply with applicable privacy regulations worldwide.

Our goal was to create a way for every website owner to find and install all of the open-source and SaaS tools technical experts use everyday. As developers ourselves, we wanted to make it possible for a developer in her basement to build the next great tool and get it on a million websites (and make a million dollars) the next day. We didn’t want her to succeed because she had the biggest sales or marketing team, or the most name recognition, but because her tool is the best.

When we began talking with Cloudflare, it was about integrating with Eager, not about being acquired. But Cloudflare presented an opportunity to grow so much faster than we had hoped. In fact, we plan on releasing our platform to Cloudflare’s millions of customers as soon as April of next year. That is a scale which we could only dream of last year.

As an app platform, scale is uniquely important to us. With millions of users we can ensure app developers that what they build will get installed and purchased. We can support thousands of apps and generate millions of dollars of revenue for developers. We can hire the best developers in the world and grow our team. We can make the Internet an easier place to build great things.

This blog is perhaps not the best place to bestow Cloudflare with compliments, so I’ll leave it with this. After visiting Cloudflare’s offices in Austin and San Francisco, after meeting its co-founders, after attending the company retreat in Santa Cruz, we decided to join Cloudflare. We have already begun working on reimagining our app platform, turning it into Cloudflare Apps. Beginning in April of next year, any and every developer will be able to use our platform to get their code installed onto millions of websites.

If you want to build amazing tools for all website owners, even for the ones who don’t know how to “copy-paste and embed code”, we’re the platform for you. If you want to build a tool which can make money from small and medium sized businesses, rather than by selling to huge enterprises, we’re for you too.

We’ll be releasing more information about our app development platform in January. If you’d like to get notified when we do, let us know.

For about half the world (and about half of CloudFlare's data centers) it's already 2013. As our team (most of whom are in San Francisco) get ready to celebrate New Year's Eve, wanted to quickly look back on CloudFlare's 2012. Here are some stats that tell the story of our last year:

• Page views served by CloudFlare in 2012: 679,237,127,874

• Hits served via CloudFlare's network in 2012: 3,691,532,490,107

• Bandwidth served from CloudFlare's network in 2012: 765 Petabytes

• Bandwidth we saved our customers in 2012: 436 Petabytes

• New sites that signed up for CloudFlare in 2012: 573,177

• Threats stopped by CloudFlare in 2012: 281,701,624,076

• New CloudFlare data centers added in 2012: 10

Over 2012, we saw more than 720 million unique IPs connect to CloudFlare's network. Our best estimate is that behind each of those IPs there are 1.8 Internet users. In other words, we saw approximately 1.3 billion Internet users pass through CloudFlare's network in 2012. That's well over half of the Internet's total population of users.

We also saved a ton of time that those Internet users would have otherwise spent waiting for websites to load. If you add up all the time that people would have spent waiting for websites to load had CloudFlare not existed in 2012, you get more than 891 lifetimes worth of time saved. We're really proud of that.

We have a number of improvements, new features, new data centers, and other surprised lined up for 2013. From everyone at CloudFlare, Happy New Year! Here's to an even faster, safer Internet in the year ahead.

Earlier this week we announced how CloudFlare enabled OCSP stapling in order to improve our customers' SSL performance. OCSP stapling is awesome and improves SSL performance by as much as 30%. However, it is limited to browsers that support OCSP stapling and only benefitsCloudFlare's customers. So, until every browser vendor updates to support OCSP stapling and until every website uses CloudFlare, we wantedto see if we could do something else to improve SSL performance across the web.

CloudFlare has worked with GlobalSign since we first launched in September 2010. Prior to that we surveyed nearly every certificate authority in an effort to find one that was forward thinking enough to support what we needed. GlobalSign has been a terrific partner and is shaking up what has been a commodity industry.

Several months ago, GlobalSign approached us to talk about SSL performance. Their goal was simple: become the fastest SSL provider on the Internet. As I've written about before, whenever you visit a website over a HTTPS connection your browser has to perform a check to see if the certificate has been revoked. Depending on your browser, these checks are either over the CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol) protocol. In either case, they require a request be sent back to the certificate authority and to get a response before content is downloaded. In other words, CRL and OCSP requests inherently slow down HTTPS performance.

The amount that these checks slow down performance varies depending on the certificate authority. On average, across the industry, a typical OCSP or CRL response time can be 500ms. That's half a second. In other words, every time you visit a site over HTTPS, you waste half a second waiting for the SSL check to complete. Talking with GlobalSign we realized we could do something about that.

This morning we officially announced our work with GlobalSign to make their CRL and OCSP requests the fastest on the Internet. GlobalSign's SSL checks (OCSP and CRL GET and POST requests) are now served from our cache across CloudFlare's global infrastructure. The results have been awesome. The requests that previously averaging around 500ms are now under 100ms. At GlobalSign's scale, that means we're now saving the web about a year and a half of time every day that people would have otherwise spent waiting for web pages to load. That's crazy.

This improvement accrues to sites using GlobalSign SSL certificates, regardless of whether the sites themselves are running on CloudFlare's network. Getting more sites using SSL is critical for increasing web security and promoting new performance protocols like SPDY. If you are choosing a CA, typically a commodity decision, now there's a good reason to pick GlobalSign over the other choices: they will ensure your site is as fast as possible over HTTPS. Put simply, GlobalSign is now the fastest certificate authority in the world, and nearly 3x as fast as Symantec/Verisign.

CloudFlare's mission is to power a faster, safer Internet so working with GlobalSign to make SSL as fast as possible has been a perfect fit. Our hope is that other certificate authorities will follow GlobalSign's lead and spend the time to optimize their SSL checks for optimal performance. As an added bonus, we've also helped GlobalSign be the first certificate authority to have their SSL checks be available over IPv6. This is all part of our efforts to help build a better Internet. As we like to tweet: #savetheweb.

Wednesday, June 6, 2012 is World IPv6 Day. At CloudFlare we're issuing a challenge to every site on the Internet: it's time to support IPv6 and enable the future. CloudFlare has made supporting IPv6 free and easy. Once you're signed up for CloudFlare, it only takes a single click to use our Automatic IPv6 Gateway and join the modern web. In other words: the web is out of excuses, it's time to join the future.

We'll be migrating all CloudFlare users who haven't enabled IPv6 yet to the SAFE IPv6 mode over the next twelve days. If you're a CloudFlare user, watch for an email with details. SAFE mode mimics the same IPv6 strategy used by big sites like Google and Facebook, allowing IPv6 traffic to come to a special subdomain on your site (e.g., ipv6.example.com). We've successfully tested this since we launched our IPv6 Gateway 9 months ago and it works great. Going forward, it will be the default option for all CloudFlare users.

Beyond the default mode, we're encouraging all our users to try FULL IPv6 mode before the June 6, 2012 deadline. FULL IPv6 mode enables a "dual stack," meaning that IPv4 and IPv6 traffic can access your site without having to go to a special domain. This blog, as well as CloudFlare's website, are currently running on FULL IPv6. While last year's World IPv6 Day demonstrated there were still some networks that had misconfigured IPv6 networks, our experience is that those problems have been largely addressed. You can enable FULL IPv6 Mode for all your websites by visiting our Global IPv6 Challenge page:

www.cloudflare.com/ipv6-challenge

In addition to enabling IPv6, we want to gather data on ISPs that are not properly supporting the protocol. Next week we'll be launching the IPv6 Network Testing app. Any website on CloudFlare's network can install the app with a single click. The app runs silently on a sampleset of your pages without interfering with other aspects of the page or slowing down your page loads.

The IPv6 Network Testing app tests 1) whether your visitors have IPv6 support; and 2) whether they can support "dual stack" websites that run FULL IPv6 mode. For sites that enable the app, we will not only give you visibility for your own visitors, but we will also publish aggregate data on the overall state of the web and reach out to ISPs we discover with broken networks.

CloudFlare's mission is to help build a better web. As the Internet runs low on IPv4 address space, the web will suffer. IPv6 presents a classic chicken and egg problem. We're doing our part in helping address that problem by making it easy for anyone with a website to be available on IPv6 for free. We hope you'll help us spread the word about our Global IPv6 Challenge to your fellow webmasters, network operations teams and favorite websites.

We're proud of the fact that CloudFlare is already one of the top 5 providers of IPv6 connectivity for the largest sites on the Internet. But, as this infographic from Hackertarget.com illustrates, we still have a long way to go. Our challenge is simply: it's time for the web to stop making excuses; join us in enabling IPv6 support today. Learn more:

www.cloudflare.com/ipv6-challenge

Today Google celebrated the birthday of Bob Moog, the creator of the Moog keyboard, with an interactive doodle. If you haven't played with it, it's pretty cool. Check out, for example, this version of the Legend of Zelda theme music composed with today's doodle.

The top result when you search for Moog on Google is MoogMusic.com. The site celebrates Bob Moog's legacy and sells versions of his keyboards and other devices (including a pretty sweet iPhoneapp). Google contacted the site owners to give them notice that there was going to be a doodle four days ago. The only catch, they had to keep the information strictly confidential until the doodle went live in Australia (the first region to see new doodles every day). Oh, and, by the way, Google noted, they should prepare for a crushing load of traffic to their website.

That presented a bit of a conundrum. Moog Music turned to their web developers, a technically savvy shop called PurpleCat.net. The site was designed to handle half a million hits a day, so the team at PurpleCat spent the next threedays making several improvements to the site to increase its capacity. They migrated the site to new hardware, secured a dedicated gigabit port, migrated the mysql database to its own server, upgraded the backend of the site replacing Apache with NGINX and added layers of caching and optimizations. Needless to say, it was a busy three days for the PurpleCat team while they did all the upgrades to prepare for the traffic surge. The site, however, was on a single virtual private server (VPS) with limited resources and it didn't make sense to upgrade the whole infrastructure for a one-day spike in traffic.

As soon as the doodle went live in Australia and the embargo was lifted, PurpleCat called us at CloudFlare and explained what was about to happen. We were happy to help having had a lot of experience dealing with floods of traffic from events like these. The MoogMusic.com site went live behind CloudFlare and we saw the trafficbegin to rise.

Things were ok at first, but as the sun rose in Asia, errors started to be returned from the stressed MoogMusic.com VPS. CloudFlare's Always Online technology kicked in and served cached versions of the page, but the dynamic portions were at times inaccessible and the pages loaded slowly as our servers waited for a response or timeout from the backend. It wasn't ideal.

We knew we could help even more, so our support team worked with the folks at PurpleCat to setup Page Rules for the MoogMusic.com site. While some of the site is dynamic, large portions are relatively static. That meant a Page Rule could define the static portions -- like the front page and a history of Moog's legacy -- and instruct CloudFlare to Cache Everything, even the HTML. That means we will serve all requests to the pages that match the rule from our infrastructure without any requests getting sent to the VPS.

The results were dramatic. Approximately 92% of requests that would have previously hit the VPS were instead fielded directly by CloudFlare. We also reduced bandwidth needed to serve the requests to MoogMusic.com by more than 90%. With all the static requests offloaded to CloudFlare, the VPS had plenty of capacity to return the dynamic, uncachable HTML of the site.

MoogMusic.com is currently averaging more than 100 requests per second. (What's pretty incredible is that's less than 1/1,000th of CloudFlare's overall load.) The VPS is doing more traffic every 15 minutes than the VPS it's running on is designed to handle over 24 hours. Peter from PurpleCat sent us a nice post thanking us for our help. He also shared the following with John on our team:

your ceo will like this.we built a separate server to just serve this page up:

http://190-2.purplecat.net/

But thanks to cloudflare, we never had to put it up.

He's right, I do love that. And so does everyone else at CloudFlare. It's exactly why our whole team comes to work every day excited to solve what seem like impossible challenges... like scaling a single VPS to deal with the traffic from the Google doodle.

Just a quick update on the initiative between CloudFlare, OpenDNS, and the DCWG to clean up the DNSChanger malware. In the last week, just over 11,000 websites enabled the Visitor DNSChanger Detector App through CloudFlare. Since then, those sites have collectively served more than 56 million page views. Just over 12,000 visitors to those websites have seen the warning about the DNSChanger virus and clicked on the link to learn more and clean up their infection. In just the first week, that's nearly 4% of the total number of estimated infected computersthat the CloudFlare community has already helped notify and get cleaned up.

While hundreds of thousands of computers are still infected and risk losing access to the Internet on July 9, 2012, we're proud of the strong start to this effort by the CloudFlare community along with OpenDNS and the DCWG.

If you haven't yet enabled the Visitor DNSChanger Detector App for your sites on CloudFlare, you can do so by following this link.

Thanks for helping us #savetheweb.

Several years ago, some suspected cyber criminals on the Internet wrote a family of malware dubbed DNSChanger. About a year ago, law enforcement tracked down the suspected cyber criminals behind this malware, arrested them, and took over the servers they were using to redirect customers to rogue sites.

As a result of a court order, the Internet Systems Consortium (ISC) under the direction of the FBI, has continued to run the DNS servers used by the malware for the last year. However, the court order will soon expire and those servers are scheduled to be shut down on July 9, 2012. When that happens, hundreds of thousands of Internet users whose systems are still infected and/or affected could lose access to the web, email, and anything else that depends on DNS. This is the story of how two Internet infrastructure startups — CloudFlare and OpenDNS — are playing a small part to help solve the problem.

Up front, in order to understand this story, you need to understand there are two types of DNS servers: recursive and authoritative. Everyone who uses the Internet needs a recursive DNS server. Your ISP usually provides these types of services or you can use a provider like OpenDNS, Google, DNSAdvantage, other public resolvers, or even run a server yourself to handle your recursive DNS queries.

On the other hand, every domain needs at least one authoritative DNS server. Authoritative servers are where a particular domain's records are hosted and published. Many domain registrars provide authoritative DNS servers, or you can use a service like CloudFlare and we provide authoritative DNS. When an Internet user types a Universal Resource Identifier (URI) aka Universal Resource Locator (URL) into their browser, clicks on a link, or sends an email, their computer queries their recursive DNS provider. If the recursive DNS provider has the answer cached then it responds. If it doesn't have the answer cached, or if the answer it has is stale, then the recursive DNS server queries the authoritative DNS server.

As mentioned above, OpenDNS provides recursive DNS. Their customers are web surfers and they provide a terrific service that helps speed up Internet browsing and protect people on the web from malware. CloudFlare provides authoritative DNS. Our customers are websites and we make those sites faster and protect sites from attacks directed at them. While we're often asked if OpenDNS and CloudFlare are competitive, in reality both services are complementary just using different parts of DNS (recursive and authoritative) to achieve a similar mission: a faster, safer, better Internet.

The DNSChanger malware family was designed to change the recursive DNS server that Internet users' computers queries. Instead of directing DNS queries at the recursive server you or your ISP configured, the malware modified computer settings to route queries to recursive DNS servers controlled by the suspected cyber criminals.

The job of DNS is to translate a domain name such as dcwg.org, which humans prefer, into an IP address, like 108.162.205.64, which servers and routers can use. If you are a cyber criminal and you can gain control over someone's recursive DNS then you can direct traffic to certain sites to a fake version of the site. Once DNSChanger had web surfers querying rogue recursive DNS servers, all requests for legitimate websites could be directed to a fake website. For example, even if you typed your bank's domain name into your browser, if the suspected cyber criminals control recursive DNS then they can send you to a malicious site and steal your information.

Over the years DNSChanger operated unchecked, more than a million computers and home routers had their DNS configurations modified. Thankfully, law enforcement was able to track down the suspected cyber criminals behind the malware, arrest them, and seize control of the rogue recursive DNS servers. Unfortunately, hundreds of thousands of computers are still using the formerly rogue recursive DNS servers. On July 9, 2012 the court order directing ISC to operate the servers expires and those servers are scheduled to be shut down. On that date, all systems which still have their DNS settings modified by DNSChanger will effectively be cut off from the Internet.

The DNSChanger Working Group (DCWG), a loosely affiliated organization comprised of some of the world's largest and most competent ISPs, search engines vendors, software vendors, security companies, and others, has been working to get the word out about the problem and reduce the impact of the shutdown of the DNSChanger recursive servers. The DCWG launched a website (dcwg.org) to provide information about the malware, let people test whether they are infected, and provide recommendations on how to fix their systems. CloudFlare first became involved when the folks at dcwg.org reached out to us because their site was under heavy load after attention from major media outlets. CloudFlare helped keep the dcwg.org website online under the load caused by media attention over the last 10 days. We offloaded more than 95% of the traffic to the site, ensuring the site ran fast and stable even when it was being featured on the front page of cnn.com.

Unfortunately, one of the challenges in trying to address situations like DNSChanger is that you only know to go to the dcwg.org website if you already know about it. What you needed was something akin to an emergency broadcast system that would inform people who were infected that they had a problem as they surfed the web. In the process of working with the DCWG, we realized we might be able to help.

Some of our engineers created an app named Visitor DNSChanger Detector App. Any website on CloudFlare can enable the app with a single click from our apps marketplace. The app installs a small bit of Javascript on the page that tests visitors to see if they're infected. If the tests do not detect anything, nothing happens. If the tests indicate that the DNSChanger recursive servers are being used, then a banner is displayed across the top of the page and visitors are directed to instructions on how to clean up the infection (more on that in a second).

More than 470 million people pass through CloudFlare's network on a monthly basis. Our data suggest that more than half of the people infected with DNSChanger would visit at least one site on CloudFlare per month. Thepower of the Visitor DNSChanger Detector App is that as CloudFlare publishers enable it then there is an increasing likelihood that people who are infected will get information about their infection before they are no longer able to use the Internet on July 9, 2012.

While we've made it extremely easy for publishers on CloudFlare's network to help get the word out, we didn't want to restrict participation to only those sites using our service. We therefore decided to release the code for the checks publicly and as open source so anyone who can install a few lines of Javascript on their web pages will be able to install it on their own sites to inform their potentially infected users. You can access the code from the following GitHub Repo. We're hopeful that sites both large and small will take the time to install the code in order to help inform their visitors who may be infected.

While CloudFlare is able to assist with informing web surfers they have an infection, we aren't particularly well situated to actually fix the problem. After all, it isn't our customers that are directly impacted,but rather the customers of our customers. Many of the folks infected can get help from their ISPs, but for some this might not be an option. CloudFlare reached out to David Ulevitch, the CEO of OpenDNS and he saw this as a great opportunity to further OpenDNS's mission of helping build a better Internet. We added OpenDNS as aresource for publishers to display to their customers when the Javascript detects the use of the DNSChanger recursive servers.

This incident illustrates to me the importance and power of the DNS system that underpins the Internet. The suspected cyber criminals were able to modify DNS settings to steal advertising revenue and perform other illegal activities. CloudFlare uses authoritative DNS in order to provision powerful tools to make sites faster and even help create a sort of emergency warning system for the Internet. OpenDNS provides high performance recursive DNS caching services for their customers. Combined, we hope to help the DCWG get the word out so the hundreds of thousands of Internet users still impacted by the DNSChanger malware will be able to take steps to ensure they'll be able to use the Internet on July 10, 2012 and beyond.

Photo by NASA / Unsplash

On January 26, CloudFlare joined the "World IPv6 Launch" being organized by The Internet Society. If you haven't heard about it, it is an effort to encourage companies commit to "permanently enable IPv6 for their products and services" by 6 June 2012 -- see http://www.worldipv6launch.org/ for details.

Of course you might ask "Wait. I thought CloudFlare already supported IPv6?" Indeed we do, and we're proud that we've helped grow the IPv6 Internet significantly. As Matthew mentioned in a recent blog post, we are already providing IPv6 web service to 10% of the Alexa top 1 million websites that support IPv6.

Unfortunately, currently, only about 1% of the top million websites support IPv6. We'd like to help significantly increase that percentage. We believe this is important because we feel IPv6 provides the best way to allow the Internet to continue to grow and be a platform for innovation. Without IPv6, connecting to the Internet will become increasing expensive (as the costs ISPs must pay to obtain IPv4 addresses increase) and fragile as people are forced behind increasingly complex and error-prone Network Address Translation technologies.

While we have some ideas on how to encourage more of our customers turn on our Automatic IPv6 Gateway, we'd like to ask you for your suggestions: what can we do to help break the IPv6 chicken-or-egg problem? How can we help motivate ISPs to offer IPv6 support when there's little content is on IPv6? And how can we motivate content providers to put their content on IPv6 when so few ISPs support it?

We're working to make IPv6 support as easy as possible, but if there's more we could be doing, please let us know.

We regularly monitor the Alexa top 1 million websites for trends. Specifically, we've been tracking how many of them support IPv6 connections. The numbers are still low but have been improving. About 1% of the 1 million largest websites on the Internet now accept and properly support IPv6 connections. What's pretty cool is that about 10% of those that do accept IPv6 connections do so via CloudFlare's free Automatic IPv6 Gateway. There's a long way to go, but we're proud of our part of expanding the modern Internet.

CloudFlare launched publicly exactly one year ago today. In that year, we have grown from virtually no traffic to powering more than 15 billion page views for 350 million unique visitors in the last month. Today, to celebrate CloudFlare's birthday, we thought we'd give our users a present in the form of a new feature.

CloudFlare set out to solve the Internet's biggest challenges. One of the challenges a lot of people talk about, but few people are doing anything about, is the transition from IPv4 to IPv6. That changes today.

The IPv4 protocol was designed in the 1970s. It was built to accommodate about 4 billion devices connecting to the network. That seemed like a lot at the time, but the explosive growth of the Internet means we're closing in on that number. In order to grow, a new protocol was created: IPv6.

Unfortunately, the IPv4 and IPv6 networks are incompatible. Unless you have a gateway of some kind, if you're on one you can't visit websites on the other. And, even more unfortunately, the gateway solutions typically are hardware-based and cost tens of thousands of dollars per website to deploy. This means that most the world's websites are unavailable for the 1% of the Internet that is already using IPv6. And the percentage of users on IPv6 is only going to grow.

At CloudFlare, we realized we were in a unique position to solve this problem. Today we're publicly launching CloudFlare's Automatic IPv6 Gateway. To enable it, sign up for CloudFlare or login to your account and visit your CloudFlare Settings page at:

CloudFlare.com > My websites > Settings (pull down menu) > CloudFlare settings

You can choose two options: (FULL) which will enable IPv6 on all subdomains that are CloudFlare Enabled, or (SAFE) which will automatically create specific IPv6-only subdomains (e.g., www.ipv6.yoursite.com). You do not need to change any of your DNS settings. After it is up and running, you can test your IPv6 compatibility and get a badge for your site.

We are providing the Automatic IPv6 Gateway for free to all CloudFlare users. We started CloudFlare in order to help solve some of the Internet's toughest challenges. We are proud on our first birthday to be doing our part to help solve another one.

Not yet a CloudFlare user? Sign up for free today.