Guest Blog

You probably have IPv6. Turn it on!

Kyle Drake, founder of Neocities, a free web hosting service, shares his experience with implementing IPv6. This post originally appeared on APNIC’s blog.

Guest blog post by Kyle Drake

Thanks to a massive amount of time and effort, there are now a large number of ISPs, data centres, cloud services, and software that now support IPv6 in the United States and around the world. Actual adoption of IPv6 in production is slowly increasing globally, but is still lower than it could be.

With this post, I not only want to convince you to start looking into beginning to use IPv6 on your own computer, but show that in many cases, enabling IPv6 can be as simple as clicking a button on your WiFi router.

Turn on IPv6

You might already know the reasons why IPv6 is so important: we’ve now run out of available IPv4 addresses, and it’s now very expensive to acquire new IPv4 addresses (in the ARIN region, you likely have to buy them from others), hampering the ability for network operators to provide infrastructure services at reasonable costs.

There are also significant security benefits to IPv6. One of the ways exploits are propagated is they scan the entirety of the IPv4 address range looking for vulnerabilities. As the IPv6 address range is so large (128 bits), it becomes impossible to scan the entire range. There was a great recent blog post on The Internet of Stupid Things that highlights the serious security problems we’ll have with IoT if we don’t deal with the address scanning problem, to say nothing about the problem of not even remotely having enough IPv4 addresses to support that many devices.

Considering the many benefits of IPv6, you may be wondering when you’ll be able to start using it. The answer is, probably now. And it might be easier than you realise.

Getting my feet wet with IPv6

I wanted to see if I could get IPv6 support for Neocities, which started my investigation into the current state of IPv6. At that point, I didn’t really know a lot about actually using IPv6. Before I enabled it on my servers, I wanted to get it working on my laptop and home network. I didn’t just want to ping the server from another server, I wanted to test the complete end-user experience myself.

The first thing I did was contact my ISP to see if they supported IPv6, and it turns out they did. Surprisingly to me, this is already true for many (if not the majority) of ISPs in the USA. Comcast, Time Warner Cable, Verizon, Cox, AT&T, Charter, and CenturyLink all have active support for IPv6, and that’s just the largest ISPs in the United States, representing approximately 78 million subscribers.

The way these ISPs provide IPv6 today is with a “Dual Stack” configuration, essentially providing both an IPv4 and IPv6 address at the same time. This allows you to start getting your feet wet with IPv6 while still supporting sites and software that haven’t switched over yet.

After confirming support from my ISP, my next goal was to figure out how to actually turn it on.

Configuring your WiFi router

If your ISP supports IPv6 and you have a modern WiFi router, this may be the only thing you need to actually configure to get IPv6 working on your home network.

My personal computer only had an IPv4 address being assigned to it from my WiFi router (which I confirmed by visiting an IPv6 test site?, so something clearly needed to get configured on it to enable IPv6.

I started by logging into my WiFi router (a D-Link DIR-868L) and quickly realised that it not only supported IPv6 but that I was one click away from enabling it. The router informed me that it would go into an automatic setup mode which would take a few minutes, then it would reboot with IPv6 support. I clicked the button and went for a cup of tea. Before I came back, the WiFi router had rebooted, and my local network now magically had a dual stack IPv4 and IPv6 address assignment and had bound seamlessly to the modem’s IPv6 address assigned by my ISP.

D-Link’s firmware was the easiest I saw for IPv6 configuration, but I also upgraded a network running a CenturyLink router that was fairly easy (though a few steps were somewhat obtuse), and another router running OpenWRT, which has excellent IPv6 support.

Most routers provide pretty good IPv6 support at this point but unfortunately, there are exceptions. Notably, I was surprised to learn that DD-WRT IPv6 configuration was ridiculously complex, and I didn’t feel bold enough to try to enable it. I’m hoping that DD-WRT can work to improve this in the future.

Trying it out

Now that my home network was set up, I focused my attention on enabling IPv6 for my laptop. At this point I braced myself for a headache, assuming the process would be a harrowing effort of digging through complicated config file muck, fixing broken, incomplete or badly configured software.

Here again, I was pleasantly surprised at how easy this process was. I simply rebooted my computer and had IPv4 and IPv6 support running on my machine. Great! But now how do I actually use it with my web browser?

It turns out that was seamless, too. In fact, it’s so seamless that it took me a while to figure out if it was even working. This is possible because most web browsers (I tested Firefox and Chrome) automatically determine whether they should use IPv6 or IPv4. When you type in a domain name, they automatically look for an AAAA record (the DNS A record for IPv6). If it exists, it tries using IPv6, falling back to the A record and IPv4 if necessary. I noticed no performance reduction in this process, though there could be a minor, unnoticeable difference.

The new “problem” was that I couldn’t visually tell when a site was loading with IPv4 or IPv6. To give me better insight into this, I installed the IPvFox add-on, which put a small icon in my address bar that would tell me if the site was loading with 4, 6, or with a combination of the two (Chrome also has a similar plugin called IPvFoo). I strongly recommend installing these plugins to assist you with testing IPv6 support. In addition, it also provides an interesting insight into which websites currently support IPv6 (a surprisingly large number), and which currently don’t.

Many websites have IPv6 support and don’t even realise it. For example, cloud proxy services such as Cloudflare provide IPv6 support transparently to the site they are proxying, whether the upstream web server supports it or not. Their aggressiveness in adopting cutting-edge technology for their infrastructure is notably helping to improve IPv6 adoption, and in fact, could even be responsible for the majority of web servers that currently support it.

Enabling IPv6 for the servers

Now it was time to see if we could enable IPv6 for the Neocities servers. I first went to the server that powered our web application (the front site), and saw that an IPv6 address had already been provided by our data centre operator, and automatically configured on our server.

If your data centre or cloud provider doesn’t automatically provide an IPv6 address, they usually provide an option to get one through a web interface or by contacting support. Once the server has been assigned an IPv6 address, you need to configure your server to use it. Each operating system has a unique way of configuring networking, so follow the relevant documentation to see how to enable IPv6 for your specific OS.

Once the server has been assigned an IPv6 address, I needed to configure the web server software to use it. Like many (if not most) online providers, we use Nginx for both serving sites we host on Neocities, and for proxying our backend web application. So I needed to configure nginx to start listening on the IPv6 address, in addition to the IPv4 one.

We use a custom compile of nginx that’s tuned for our needs, so I had to enable IPv6 by adding –with-ipv6 to the ./configure before compiling, but if you use the prebuilt nginx that comes from software packages, you likely won’t need this step. Once it was compiled and installed, I only needed to add a line to nginx.conf to tell it to also listen on IPv6:

server {
listen 80;
listen [::]:80;
# … the rest of your server config

I then reloaded nginx, and voila, IPv6 support! When I was ready, the last step was to add an AAAA record for that server to my nameservers. Within minutes, users with IPv6 support started automatically using that address, perhaps without even realizing it.

Minor tooling differences

In the process of testing IPv6, I did notice some mild software differences that initially made it difficult for me to test things, and I wanted to mention them briefly. The first notable difference was that I had to wrap the IPv6 address in square brackets for my web browser.

For example, if I wanted to access http://234::3334::44, I had to type it in as http://[234::3334::44]. I also had to use ping6 instead of ping, and use -6 with curl in order to force IPv6. And SSH would fail with square brackets, so I had to leave them out.

Having to deal with these quirks was honestly a little annoying. The one thing I particularly don’t like about IPv6 is weirdness of the colon delimitation. It’s a bit annoying to have to work with it, and I agree with some other writers that think we could do better in this category. It would be nice to see some improvements here in the future, but it’s not a deal breaker for me for the IPv6 adoption we need.

The crazy things IPv6 can do

Lastly, I wanted to mention some pretty interesting experimental projects people are already using IPv6 for. Specifically, I wanted to mention Cjdns, an experimental project that uses private keys to derive IPv6 addresses, enabling trustless distributed routing networks. This works because IPv6 addresses are so large (128 bits), that it’s safe to simply derive them randomly from keypair cryptography. In the future, this could help to address problems like route poisoning and related problems with the present Internet’s trust-oriented routing infrastructure. It’s experimental at this stage, but still a very interesting example of what IPv6 could hold for the future.

IPv6 doesn’t just allow us to add more devices to the Internet; it also enables the possibility of re-architecting the Internet to improve performance, upgrade security, and increase privacy. I’m excited to see what comes next.


All of my ISPs, data centre operators, and cloud service providers supported IPv6. But in many cases, I had to click an extra button to enable it, or explicitly request it. I understand the motive for doing this, as they perhaps wanted to avoid creating any issues with bugs or opening up any unknown security holes. I come from a similar school of thought (don’t turn anything on unless you really need it), but I’m now going to make a rare exception for IPv6.

Router manufacturers, data centres, cloud services: I love how easy you’ve made it to enable IPv6, and I appreciate the hard work you did to enable it, but now’s the time to go one step further. No more “one extra click” or “on request” support: it’s time to enable dual stack IPv6 support by default. When WiFi routers and servers start automatically configuring IPv6 alongside IPv4, we’re going to start seeing a lot more adoption of IPv6. And the farther along we get, the closer we get to being able to finally deprecate IPv4.

This particular technology is working best when its functionality is invisible to the end user. Thanks to the amazing work everyone has put into making IPv6 seamless, most users won’t even notice they’re using it, as everything they do today will continue to work with no noticeable difference. There’s only one thing left for you to do: Turn it on!

Kyle DrakeKyle Drake is a tech entrepreneur and the founder of Neocities.






Christmas Gift Idea: Some IPv6 Experience

A holiday gift from the community to the community.

Guest Blog Post by Marco Hogewoning, External Relations Officer – Technical Advisor at the RIPE NCC

The holiday season is rapidly approaching and this year is coming to a close, another one done and another one that saw some great and wonderful and also unfortunately some sad moments.

One of those key moments was the depletion of the IPv4 pool in the ARIN region, which for some probably means the sad realisation that their business models will hit a growth barrier. Others celebrated it, with a smug I told you so face, as the moment where IPv6 is no longer optional but a requirement for a solid Internet-based business.

It was something we have seen coming and the Regional Internet Registries and countless businesses have been preparing for this moment for years. Where other regions such as APNIC, RIPE and LACNIC already depleted their pools and activated various austerity based IPv4 policies, we had the opportunity to learn from each other and share experiences on what to do when the final moment of imminent IPv4 depletion would be there.

The same goes for the deployment of IPv6, where countless businesses and governments, big and small, have started to activate it in their products and services. We have come a long way, and I am happy to see countries all across the globe are making such great progress in IPv6 deployment, with the US market not that far behind the world’s IPv6 leader: Belgium.

At the same time we must not forget that a lot of people still face the challenge of starting an IPv6 project, scratching their heads on where to start and looking for the secret recipe that made others successfully deploy IPv6 for millions of customers.

IGF 2015 IPv6 BPF Session

As part of this year’s inter-sessional work for the Internet Governance Forum (IGF), a group of RIR staff and community members set out to collect and document those experiences. We’ve asked countless people from all stakeholders to tell us their stories and share what they thought were the secret to their success.

After a great workshop during the 2015 IGF in Brazil and a public comment period, the resulting best practice document Creating an Enabling Environment for IPv6 Adoption document has now been published as output of the IGF.

From the start we decided that it should not be another technical description of IPv6, many of those exist already and your favourite bookstore is likely to have a few really good books with a level of in-depth knowledge that we would have never been able to write up in the few months we had.

Instead we focussed on coordination and motivation, describing successful stories of IPv6 task forces, business and governments coordinating their IPv6 deployment and triggering in a domino effect where the success of one party offers motivation for others to join and do the same.

Above all, what is important, is to know you are not alone out there. You might be one of the lucky ones who have IPv6 already done, you might be somebody under pressure to start the project. We can all learn from each other, so why not give somebody the most valuable gift of all? Knowledge.

We got some of it together, but please keep adding yours. Share your experience and knowledge on IPv6 with others using the RIR blogs, NOG meetings and join your local IPv6 task force, also especially when you have already deployed.

Consider it a gift from the community to the community. The IGF outcome document can be downloaded here from the IGF website.


Marco_Hogewoning112x165Marco Hogewoning is External Relations Officer – Technical Advisor with the RIPE NCC. As part of the External Relations team, he helps lead the RIPE NCC’s engagement with membership, the RIPE community, government, law enforcement and other Internet stakeholders.






To Squat or not to Squat?

Cathy Aronson’s crash course in ISPs adding to RFC 1918 space with unrouted IPv4 address blocks.

Guest blog post by by Cathy Aronson


Recently I got an email from a colleague at a sizable ISP. He said his boss wanted to know whether it was safer to use or for additional RFC1918 address space.

I have to say I was shocked. I thought maybe I didn’t understand him. I rewrote back, “Are you saying that you are going to use and as additional RFC 1918 space?” His answer, “Yes”. I was shocked. I did not know this was happening. Certainly this had to be an isolated incident? It is an incredibly bad idea for so many reasons that I’ll talk about as I go on here.

Since I was on my way to IETF 94 in Yokohama the next week I decided to look into this matter and see who is doing this. A number of people talked candidly to me about this situation.

Before I left on my trip I did some googling to see what I could find out there on the net about this. I have attached some links below. It amused me that a large number of folks out there are seeing these addresses in their traceroutes and thinking it’s government surveillance. Of course that’s not at all the case. The not so amusing part of my googling was that there is a lot of this squatting happening out there on the net.

It turns out there are a LOT of organizations considering squatting on other organizations address space. Some of them include large ISPs, cable providers, and large enterprises.. The blocks used are not just and but there are discussions (see links below) of companies using and

I talked to another colleague at a large enterprise that is currently using He heard that the UK Government (the block belongs to the UK Ministry of Defense) may soon sell their rights to this block and it will be globally routed. There are folks trying to persuade the UK government to not sell, but it worth a tidy sum of money.

So why is this a bad idea? It is a bad idea because someone else holds rights to these blocks. If the rightful entity decides to route them or transfer them to someone else who then routes them, then everyone has a problem. The network that is squatting will not be able to get to the legitimate users of the block. The legitimate user of the block will not be able to get to a sizable number of eyeballs on those squatting ISPs’ networks.

How likely is this problem to occur? I would think that due to IPv4 address exhaustion it will become likely that some of these blocks will end up in the global routing table. For a while IPv4 address blocks will be worth quite a bit of money and it will be tempting for owners of such blocks to transfer them to whoever is willing to pay the most.

When a block like this becomes routed globally any ISP who is squatting on the space has to quickly renumber a large number of devices. This is not a trivial amount of work. That time would be better spent connecting all these internal devices via IPv6.   At least one ISP I talked to said they were using some squat space as an interim step until all the devices could do IPv6. I am not sure why others are not spending their time and energy deploying IPv6, but they are setting themselves up for a major crisis in the future.

Links of discussions of this squatting:

These are about

These are about

These are about

Some other providers who are doing this:


Cathy AronsonCathy Aronson has been an active ARIN participant since 1998. Cathy was also on the original ASO Address Council.  Cathy acts as an advocate for address policy by volunteering to do many presentations to get involvement of other communities such as NANOG.  She feels that cross pollination of ARIN with other RIRs as well as ARIN with other networking groups is essential to making good address policy. Cathy was most recently a network engineer at Cascadeo Corporation where she helped manage addressing and routing for a number of clients.

Previously, Cathy was a member of the technical staff at Packet Design, where she was responsible for operational aspects of their Internet scaling projects. Earlier Cathy was at the @Home Network where she was responsible for routing and IP addressing. She began her career at Merit, Inc. where she worked on the NSFNET Backbone. Cathy designed and implemented the OSI/CLNP for the Energy Sciences Network. Although OSI/CLNP was never widely deployed, the experience has given greater insight into addressing and scaling issues. Cathy joined the Advisory Council in June 1998 first serving an interim six-month term before being re-elected later that year to a three-year term. She was re-elected to the AC in 2001, 2004, 2007, 2010, and 2013. Her term expires 31 December 2016.



Connecting Canadians with the New Internet

At ARIN 36 in Montreal last week TELUS co-sponsored network connectivity, bringing IPv6 to all NANOG and ARIN meeting attendees.

Guest blog post by Matthew Wilder

We Canadians are generally known for hockey, poutine and our overwhelming politeness. I’m very sorry about that. Believe it or not though there is such a thing as Canadian pride. Perhaps not surprisingly it is a polite form of pride, one which comes with a dash of bashfulness.


True to form, we at TELUS are proud of our support of industry meetings that have been held in Canada over the last several years. We have sponsored these meetings by providing network connectivity for ARIN meetings in Toronto (2010), Vancouver (2012) and now in Montreal (2015) and similarly IETF and NANOG meetings. In 2012 we were incredibly happy with our progress in constructing our IPv6 capabilities, introducing native dual-stack service for these meetings.

Fast forward a few years to 2015 and we have made a great deal of further progress. We now offer IPv6 to enterprise customers on their Internet services, and are in the midst of the mass roll-out of our IPv6 service for consumer Internet services. These efforts are finally beginning to bring Canada into the picture of global IPv6 adoption.

In June, Canada was at 0.5% user adoption of IPv6. As of October that number is 2.18% and growing quickly. This growth can be accounted for with our deployment to hundreds of thousands of homes whose Internet service now includes IPv6 connectivity. We’re extremely happy to help Canada join the rest of the pack!


Matthew WilderMatthew Wilder is a Sr Engineer in the Technology Strategy team of Vancouver based TELUS where has worked for 10 years.  TELUS is Canada’s fasting growing national telecommunications provider with 13.9 million customer connections, including 8.4 million wireless subscribers and 1.5 million high-speed Internet subscribers. Matthew’s responsibilities include IP address management, IPv6 strategy and network performance for all Internet services.  He has been an active member of the ARIN community as well as both NANOG and IETF, each of which TELUS has continually supported through network sponsorship for meetings held in Canada.



Embracing the Shift in the Internet’s Architecture

True leadership means putting your money where your mouth is.  Jeff Urbanchuk explains how Stanton Communications encourages all PR professionals to adopt IPv6, but not before making their own website ready for the new Internet Protocol. 

Guest blog post by Jeff Urbanchuk

Earlier this month, PRNews featured an editorial penned by our CEO, Peter Stanton, on the need for PR professionals to take a critical look at their network infrastructure in relation to IPv6. The editorial was written with IPv4 depletion in mind, but also served to give our peers in the PR industry a window into our recent experience transitioning the firm’s website to a native IPv6 platform.

As communicators, PR professionals take pride in being early adopters of new technologies. Our clients expect that their messages will get to the right audiences in the most resonant way. In today’s fast-paced marketplace of ideas, that usually means communicating over the Internet through blogs, social media and digital advertising. While the results of these efforts are generally measured in the final outcome of likes, conversions and page clicks, the methods by which those messages are transmitted are of equal importance. Real leadership in today’s crowded media market requires a deeper dive into understanding not only the way people communicate online, but how that communication happens on a substantive and technical level.

The move towards IPv6 is critically important for the public relations community to understand and embrace. While ISPs and device manufacturers have been baking IPv6-compatibility into their products for years, PR firms and many digital specialists have failed to pay attention. Failure to recognize the shift in the Internet’s architecture opens a dangerous blind spot that could threaten to expose clients – and the firms themselves – to an otherwise preventable competitive disadvantage.

As strategic counselors, PR professionals have a responsibility to point this fact out and offer recommendations to eliminate this blind spot. One of the best ways to do that is for agencies to undertake their own internal website review to get their sites IPv6 compatible. That’s just what Stanton Communications did.

Admittedly, it wasn’t an easy process. We are a small firm with a small IT department so it took time to learn the ins and outs of how we could make our website available over IPv6. Through our experience we worked with ARIN to develop an infographic that lists the step-by-step approach you can take to make your website ready for IPv6.

IPv6 Step by Step

In the end we learned a truly important lesson. One cannot truly appreciate, or alone promote, a technology without first personally testing and adopting that technology in real world conditions. It’s one thing to declare leadership in technology through mastery of applications and programs. It is quite another to take the step to alter your firm’s infrastructure to stay current with the rapidly evolving world of technology.

Now we are prepared, tested and ready to assist ARIN in communicating the importance of IPv6. As members of the technical community who are instrumental in keeping the Internet running, we hope you will join us in the effort.


Jeff Urbanchuk Jeff Urbanchuk is an Account Manager at Stanton Communications where he oversees strategic communications campaigns for public policy and technology clients. Jeff is a member of the Stanton Communications team supporting ARIN in its ongoing effort to popularize IPv6 through its Get6 campaign.





Are Service Providers Ready for IPv6?

President and CEO of Incognito, Stephane Bourque, is looking find out what strategies communication service providers are using to transition to IPv6 and needs your help to answer a few questions about your IPv6-readiness.  

Guest blog post by Stephane Bourque, President and CEO of Incognito Software Systems

Worldwide, the transition to IPv6 has begun — but just how ready are communication service providers for this change?

ARIN is expected to join regional Internet registries in Latin America, Europe, and Asia Pacific in exhausting public IPv4 addresses soon. Globally, this means that the number of remaining public IPv4 pools available to service providers to hand out to customers is running out, and most providers will need to consider strategies for IPv6 to enable future growth.

What are these strategies? That’s what we want to find out. For the second year, Incognito is running a global survey of communication service providers to find out IPv6 plans and strategies. The 5-10 minute survey is open to telecommunications, cable, mobile, satellite, and converged service providers of all sizes.  All participants will receive a copy of the final report compiled from survey results.

Last year’s report found that most service providers are slowly moving towards IPv6. At that stage, although more than three quarters of respondents had started preparing for IPv6, only 14% had deployed IPv6 on their networks and 4% had begun offering IPv6 addresses to end users.

Infographic 2014 Incognito Survey

The transition to IPv6 is essential for all businesses. At Incognito, we have embraced IPv6 on our internal networks and our website to prepare for an IPv6 future. When we made our website IPv6 ready in 2011, only a fraction of websites could be reached over IPv6, but we knew content was going to be a significant driver in the transition. So we enabled IPv6-support at the World IPv6 Launch Day in 2011. Our solutions already supported IPv6, so we knew we had to practice what we preach. It hasn’t been a quick process, but we look forward to being part of an IPv6 world.

Whether you are IPv6 ready or not, all communication service providers are invited to share your experiences and plans in the IPv6 Readiness in the Communication Service Provider Industry survey.


sbourqueStephane Bourque is the technological inspiration behind Incognito’s provisioning solutions. As CEO, Stephane has championed the development of high performance, multi-platform solutions that help service providers increase margins and reduce network upkeep.

Originally from Montreal, Canada, and educated at Concordia University, Stephane applied his computer engineering background at Banyan Systems to design enterprise network management systems for Fortune 1000 companies like Bell Canada.




IPv6 at the Dutch ccTLD registry SIDN

Where there’s a will, there’s a way. Senior Research Engineer at SIDN, Marco Davids, explains how Dutch ccTLD registry SIDN committed to IPv6 deployment.

Guest blog post by Marco Davids

.nl, the IPv6-enabled registry

SIDN is the registry for the Dutch country-code top-level domain. In terms of domain names per capita, we are one of the largest TLDs in the world. And even in absolute numbers, we are still among the five largest country-code TLDs. I guess that makes us kind of special. We may be a small country, but, as in so many countries, the Internet is immensely popular and has been for quite some time. In that regard, we are far from exceptional.

SIDN photoAt SIDN, we firmly believe in IPv6 as a long-term solution for the exponential growth of the Internet and the problems that arise from that. In fact, with IPv4 space running out, and prices on the secondary market rising, the need for a new addressing scheme on the internet is perhaps more acute than ever.

We are pleased to see that many organisations recognise the need for change and are acting accordingly. On the other hand, surprisingly, a considerable number of organisations haven’t even bothered to look into IPv6 at all. That is a concern. Large ISPs in the Netherlands (with a few exceptions) are moving, but they tend to take things slowly. This is one of the reasons why we are keen to promote awareness and adoption of IPv6. It goes without saying that we practise what we preach: IPv6 has been enabled on our own services for quite some time. More on that later.

The Dutch ‘comply-or-explain’ policy

The Dutch government is very much aware of the urgency of IPv6. In the Netherlands, the government maintains a so-called ‘comply-or-explain’ list, containing various Internet standards, including IPv6. Standards on the list should be used by government organisations and, for example, be part of the requirements in a procurement process. As I said, IPv6 has been on the list for quite some time, and an increasing number of government services are now reachable via IPv6. A broadly similar European list also exists, and naturally IPv6 is on that list as well.

Although we are not required to, because we are not a government agency, SIDN has decided to adhere to the comply-or-explain list. The authoritative name servers for the .nl domain have been fully IPv6-compliant for quite a number of years, but we felt we needed to go a few steps further and enable all of our services on IPv6. Naturally, we ran into a few issues. The vendor of our email appliances, for example, promised IPv6 support ‘soon’. But it turned out they needed ‘a little more time’. Quite frustrating, but also a lesson learned: be firm and serious with your vendor and make clear agreements beforehand about mutual expectations. There are still vendors out there, trying to make their customers believe that ‘no one really needs IPv6’ or claiming that IPv6 support ‘is in the next version of the firmware, scheduled for release any time soon’. My advice: show them the door.

Sometimes being pragmatic is the solution. We came to the conclusion that modifying the entire back-end infrastructure of our registry system for IPv6 was not feasible in the short term. As an interim solution, we are using load balancers to disclose our registry system via IPv6 on the Internet side, while it is still running on (RFC1918) IPv4 space internally. We also made our Whois service accessible via IPv6 in a similar fashion. So, where there’s a will, there’s often a way.

The Dutch Internet Standards Platform is a private-public initiative by several organisations with the goal of promoting new standards, including IPv6. On a simple website,, anyone can easily check the quality of their connection, or a domain name for that matter, in relation to these new standards. The test is strict; some people say it’s too strict. But if you manage to achieve a 100% score, you can at least be sure that your setup is very future proof. So try it out.

Summarising, I would say that IPv6 is here and now. It’s a mature standard that is being deployed at a rapid pace. The amount of IPv6 traffic is increasing by 100% a year.  And in the interest of an ever expanding internet, everyone should join in.


Marco DavidsMarco Davids is a Senior Technical Policy Advisor and Senior Research Engineer at SIDN, the ccTLD for the Netherlands (.nl). He has been with SIDN since 2007 and a member of the SIDN Labs R&D-team. In this capacity he is involved in various projects, primarily with a focus on the DNS. Marco is also an active participant in the RIPE and IETF communities and has contributed to several RFCs and draft documents.




A Closer Look at The Internet of Things

Nick Rojas explores the Internet of Things and how some will appreciate the fundamental changes to the Internet that will allow it to come to fruition, while others will simply take it for granted.

Guest blog post by Nick Rojas

The so-called “Internet of Things” (IoT), is not just about the seemingly endless benefits of connecting everything to the internet, or as some say, making things “smart”. It’s also about infrastructure, intellectual property, education, and increasingly growing business interests. It’s how devices are tied to the cloud for commerce, research, and an endless array of applications.

While considering the benefits of having smart refrigerators and other fun gadgets, many forget the significant potential applications that the Internet of Things could change, such as water conservation due to “smart” sensors, reducing city traffic congestion, and a radical change in health care practices.


The Main Challenge: Infrastructure

Smartphones alone command a staggering share of smart devices in use today, with more than 143 million of them in use. When phones, refrigerators, bathroom scales, football stadiums, and even entire cities collectively need to connect to the Internet, we may find that we simply don’t have the infrastructure to support this yet. When IP protocols were first designed, futurists couldn’t have envisioned all the devices that would one day connect to the Internet. The concept of connecting virtually everything to the Internet goes well beyond the original framework.

Every device connected to the Internet must be given a unique identifier to function properly, so IP address exhaustion is certainly a thing that could hinder the ability to provide for the “Internet of Everything”. This is where we can enjoy a bit of good news.

IPv4 provided approximately 4.3 billion addresses, and has lasted for about 25 years. IPv6 has been available since 1999 and vastly expands the number of addresses to about 340 trillion, trillion, trillion addresses. Simply put, we’re good to go, for a very long time.

As progress is made, some of us will appreciate the fundamental change to the Internet while others will simply take it for granted.

“There will be so many IP addresses … so many devices, sensors, things that you are wearing, things that you are interacting with that you won’t even sense it. It will be part of your presence all the time.”  – Eric Schmidt, Google’s chairman and former CEO

With Increased Connectivity comes Improved Analysis

In addition to infrastructure and the increasing number of devices, the Internet of Things will prompt the continued development of analytics. Advanced statistics and predictive algorithms will play an ever larger role in decision making.   As an example, smart devices can be used by medical researchers to track the relationship between medicines consumed and heart rate.

As the volume of people using such devices increases, and the amount of data reaches statistical significance, analyzing the data can help researchers glean valuable information about the impact of certain foods on heart rate.

According to M.V. Greene, “”The “Internet of Things,” where objects in the physical world are connected to electronic virtual networks, is poised to turn retail on its head. Not since the introduction of online shopping – and before that credit and debit cards for purchasing – has something in retail had the potential to be so transformative.”

As the applications of these smart devices are dreamed of and manufactured, the opportunities for scientists and researchers are endless. Dreaming up ways of connecting human activities with data can lead to major advances in how we lead our lives. With the recent launch of Apple’s Smart Watch, which signifies the first massive step into mass adoption of wearable technology, the potential of the Internet of Things has just begun.


Nick RojasNick Rojas is a business consultant and writer who lives in Los Angeles. He has consulted small and medium-sized enterprises for over twenty years. He has contributed articles to, Entrepreneur, and TechCrunch. You can follow him on Twitter @NickARojas, or you can reach him at







Turning Bits into Bites

I can has IPv6? Mathew Newton knows how to make IPv6 fun – by involving cats of course. Here’s how he connected a DIY device to the Internet of Things to solve a problem and make his feline friends extra happy on World IPv6 Day.

Guest blog post by Mathew Newton

If we are to believe the figures being banded around, the Internet looks set to be dominated by the number of devices connecting under the ‘Internet of Things’ banner at some point over the coming years. If there’s any domination of the Internet before then it is arguably by cats – cat photos, cat videos, pretty much cat anything. I actually think there’s room for both though in the form of Internet-enabled cat feeders

Back in 2009 I was looking for a solution to ensure our two cats didn’t go hungry if my wife and I had to work late or go out for the evening straight from work. I couldn’t help but feel that I already had half the solution by virtue of my home-grown security solution based around the use of IP cameras. We could see the cats via the Internet wherever we were, so why not feed them this way on an occasional basis also? Cutting a long story short (the full details of which can be found on my website with the obligatory cat video on YouTube) I built the first version (the ‘Mark 1’) of my cat feeder:

Cat Feeder

Aesthetics didn’t feature on the requirements list (well, not mine anyway – it turns out they did on my wife’s!) but function and reliability definitely did. It seemed to tick both of these boxes completely with little room for improvement.

That’s not to say my work was done however – I had to do something about the Cisco Catalyst switch (I know, pun intended; it was clearly meant to be!) which I’d used to interface the feeder to the network through some hacked-together RJ45 loopback adapters and piggybacking on the port status LED driver ICs. Not only was the switch noisy but also bulky and had to be tethered to a nearby network port. After rummaging through piles of kits that ‘may come in handy one day’ I found a Cisco-Linksys WRT54GL broadband router and used it to make the improved ‘Mark 2’ version:

Cat Feeder 2

Cat Feeder Schematic

Not only was the feeder now a self-contained device, but it was also wireless (well, apart from the main power) and, by reflashing the firmware, could also support IPv6! The immediate benefit of this was, of course, being able to assign an appropriate ‘vanity’ address involving ::f00d and ::feed and no doubt others! Once that novelty wore off, the other benefits became obvious – there was no messing about with port forwarding and dynamic DNS update scripts. It just worked. Out of the box. This could of course be a double-edged sword where network security relies solely on the stateful property of a NAT and so my first IoT lesson to learn was making sure that my firewall was configured to protect the feeder accordingly.

The second lesson was also security-themed, and I’ve only got myself to blame for this one. On World IPv6 Day in June 2011, I decided to open up the feeder for 24 hours for anyone to access. For those connecting over IPv4 they could only view the feeder-mounted webcams, but for those with IPv6 they could also take control of the feeder and feed the cats. You can probably imagine how it went – food pretty much everywhere and two very full cats! The real problem, however, was that some users had spotted that I was passing control parameters through the URL to a PHP script (e.g. /catfeedercontrol.php?action=feed&time=5) and so were trying to abuse this by manipulating the feed durations, fishing for other commands and goodness knows what else. I quickly added some sanity checking to the scripts to mitigate this (I didn’t do this previously because access was usually password controlled). A key point to note here is that this attack vector was not directly related to the use of IPv6 as such – the vulnerability was at the application layer after all – however the ease with which IPv6 allows devices to be reachable from the Internet highlights the importance of ensuring that security is properly considered at all layers of the stack.

Even with sanity checking I would have benefited from being able to rate limit access but didn’t have time to work out how to do this. Instead, I opted to filter the source address of repeat offenders using the firewall and this became my third security lesson. The IPv6 double-edge sword was back – the offender was either hopping between addresses (whether that be manually or using short-term privacy addresses) or an entire organisation was seemingly in on the act because the addresses were all over the place within a very large prefix! I assumed the former but given the futility of playing cat and mouse with the offender (pun not intended!) I gave up blocking individual addresses and filtered the entire prefix instead. In a ‘real world’ application this could of course have significant unintended consequences, and so it did make me realise that our approach to filter-by-address strategies in IPv4 might need further thought when it comes to IPv6.

All in all, the cat feeder has been a great success and has never let us down in the six years we’ve been using it (I should point out that we only use it on occasion and not as a substitute for in-person contact with our pets!). Indeed, the cats seem to love it although it has to be said they’d love anything that feeds them! I suspect though that they might be particularly keen on the IPv6 aspect as normally they are fed twice a day but on World IPv6 Day they were fed a total of 168 meals. So from their perspective, this answers the question as to how much better IPv6 is than IPv4… 84 times of course!


Mathew NewtonMathew has nearly 20 years of network-related experience with a particular focus on all aspects relating to the design and deployment of IP (v4 and v6) and DNS.

His interest in computing, electronics and ‘how things work’ arguably stems from a childhood of taking things apart. He is now at the level where hardly any screws are left over when putting them back together again.





Webpass Deploys IPv6 For ARIN 35 Event

The IPv4-IPv6 dual stack network at ARIN 35 last week went off without a hitch. Webpass VP of Technology, Blake Drager, explains what it took to get it up and running. 

Guest blog post by Blake Drager

ARIN partnered with Webpass, an industry leading Internet Service Provider (ISP), to provide the network for the ARIN 35 event held in San Francisco from April 12-15, 2015.

We met with ARIN to determine what type of connectivity was needed:

  • BGP
  • Webpass allocated IPv4 / IPv6
  • ARIN netblocks statically routed to Webpass WAN

Since ARIN has a specifically reserved IPv4 /20 and IPv6 /48 for ARIN and NANOG meeting events, statically routing ARIN’s netblocks within the Webpass network was the best solution.


Webpass’ network is 100% dual-stacked and running on a Brocade CER and MLXe platform so setting up the IP circuit was as simple as:

  1. Adding an IPv4 /30 and an IPv6 /64 for connectivity between networks
  2. Statically routing ARIN’s netblocks with the next-hop being the Webpass WAN IPs
  3. Redistributing the static routes into our OSPF and OSPFv3 tables

After setting up the IP circuit, ARIN’s netblocks were routing within the Webpass network, but we wanted to redistribute these blocks to our eBGP peers so we had to do the following:

  1. Create prefix lists for the ARIN blocks
  2. Add those prefix lists as an applicable route-map statement attached to eBGP neighbors
  3. Verify that the routes were being advertised to Webpass’ eBGP peers
  4. Contact eBGP NOCs, send them the ARIN LOA for  Webpass to advertise ARIN’s netblocks and request that they update their prefix lists accordingly. This took a few emails and a little coercion with some networks, but after a while, ARIN was able to verify their routes were visible in public BGP looking glasses and route servers.

Once all of the above steps had been successfully executed, and the microwave link was installed at the JW Marriott, ARIN was able to verify public connectivity for both IPv4 and IPv6. All things considered, the process was very simple. IPv6 setup required no additional configuration when compared to the IPv4 setup. This is contrary to popular narrative that IPv6 is overly complicated and makes IP provisioning more difficult. Nothing can be further from the truth. Once your network is 100% dual-stacked and your staff is appropriately trained, IPv6 provisioning gets easier.

In fact, if ARIN’s meeting requirements were for IPv6 only, the configuration would have been as simple as Webpass providing ARIN with a /56 or a /48 via DHCPv6 Prefix Delegation. DHCPv6 would automatically assign them a /48 with a next hop of their local “fe80” IPv6 address. The Brocade router would see this delegation occur (via DHCPv6 relay) and automatically insert that route into the routing table as a “delegated static” entry. This is the common Webpass customer IPv6 connectivity configuration.



Blake Drager Blake joined Webpass in 2006 and serves as the Vice President of Technology, leading the Webpass software development and network teams.  Blake started his career at Webpass building systems used to deploy Webpass’ Internet and providing technical support to residential customers. Webpass needed a scalable network that could interface with customers and employees and Blake rose to the challenge of building it. Today, Blake continues to drive software development that enables Webpass to run efficient operations.





Tinkering with IPv6 on a Home Router

Working in the IT world, Chris Harvey was naturally curious about IPv6, so he decided to set up IPv6 on his home network when it was time to upgrade his router, and now he blogs about his experience.

Guest blog post by Chris Harvey

Some may say I’m crazy, and a few of them would be right, but I’ve long tracked the growth of IPv6 given that I worked at Comcast for a number of years and my manager was instrumental in the Comcast push into IPv6. As a result it’s been fairly well drummed into me that this is something we all have to tackle at some point, or else the results of inaction will tackle everyone to the ground.

I guess you could say that I’m lucky enough to have been in the IT world for all of my career, so I’m one of many IT savvy people that are not too phased by configuring networks and getting my seemingly ever growing body of electrical devices connected to a network. Having said that, what less IT literate folks realize (I’m thinking of my mother here) is that even for those of us “in” the industry, change is usually a learning process too. We just have a level of experience to lean on that helps us catch on a little quicker than someone who’s not exposed at all.

I can clearly remember a few (ok, maybe many) years ago being completely mystified by many aspects of IT that my more senior and experienced colleagues took for granted. My point of saying this is, don’t think “it must be easy for him, because he knows what he’s doing”. Well actually most of the time I don’t, I’m just trying things and seeing the results. I may be able to interpret the results faster than someone with no experience, but I don’t have a magic wand that instantly makes me understand the new technology any more than my mother leaning on years of cooking experience to realize that leaving that toast in for just a bit too long is going to burn it.

Being “in” the industry always makes me lean towards new projects like initiating IPv6 with both a little excitement and trepidation. For my wife it’s more a dread of “oh great, now I’m going to lose my husband to the computer for two days while he figures this out, and in that time nothing else will get done”. That being said, it was time to upgrade my router from Comcast. I’d received a few emails saying it needed upgrading, so I decided to make the change knowing that the next generation of DOCSIS 3 modems would finally give me access to IPv6 for all my computers, tablets, phones and other ancillary and ever-connected devices in the house.

Frankly, enabling IPv6 couldn’t have been easier. Of course I made it much more complex by trying to understand the changes and morph them to my own desires.  At the end of the day simply plugging in the new modem was enough of a change to enable IPv6 to the devices on my network that could already speak that language, which is about every single one of them.

Because it would be pretty boring if I just stopped there, let me give a little more detail around what I did do, what worked and what didn’t and where I’ve ended up.

Firstly, it’s worth knowing we have an almost entirely Apple-based house. There are some devices in my house that are not Apple products, such as Internet radios and wireless HVAC thermostats, but mostly it’s Apple products. OSX has been IPv6-enabled for a long time so I expected this to be relatively easy and in fact it was.

Comcast supplied the modem, and it was provisioned into the account by customer care when I picked it up. Once home, I plugged it into the power and the coax cable. It took a few minutes to get up and running, but all status lights came on correctly.

The xfinity modem by default has a home WIFI which you can either immediately use with the SSID passcode that’s provided, or using the admin interface, you can rename it. Whether you connect an ethernet cable directly to the modem or use the WIFI, it’s IPv6-enabled.

The administration screen is easy to access, although not all that obvious, but Google (or the search engine of your choice) solved that. Essentially from any of your devices that connect to the modem, either hard wired, or wirelessly through the SSID mentioned above, the admin screen can be found on and the administrative credentials are easily found online. As you’d expect, you cannot administer this from the outside network unless you specifically enable it, so just because the admin user’s ID and password are easily discovered, doesn’t mean anyone can access your router.

Since I already have an Apple Airport that is my wireless router, I wanted to keep it. The modem by default comes configured as a router, so having another one inside the network means you end up with a “double NAT” scenario. I’ve yet to find anything specifically poor about this arrangement, but it’s certainly not ideal, and it does not allow for you to have an IPv6 address on your devices. So for that reason, I put the new modem into a “bridge mode”, which essentially makes it transparent to the network and passes traffic through to my Airport which means my devices automagically obtain IPv6 addresses.

To test whether you either have or are using an IPv6 address, the easiest method is to use your web browser. There are many sites to choose from, but I found these two particularly useful: and, with the latter doing a very nice job of telling you what your browser is doing. If you want to do something a little more hardcore, you can issue the following command on an OSX terminal.

ifconfig en1


ether c8:e0:cb:1c:48:69

inet6 fe80::cbb0:ebff:f3fc:4869%en1 prefixlen 64 scopeid 0x5

inet netmask 0xffffff00 broadcast

inet6 2601:8:a80:edef9:cab0:ebff:fe3c:4869 prefixlen 64 autoconf

inet6 2601:8:a80:edef9:dd47:5cd1:eaa1:1a4a prefixlen 64 deprecated autoconf temporary

inet6 2601:8:a80:edef9:5ded:d7c2:27b8:de85 prefixlen 64 autoconf temporary

nd6 options=1<PERFORMNUD>

media: autoselect

status: active

But at the end of the day, you shouldn’t need to do this. The point of IPv6 is that it simply works, so you shouldn’t need to mess around trying to make it work. The new modem and the Airport negotiate how to handle the address allocation, and it all works smoothly.

I took a bunch of extra steps that I could document for you regarding setting up my guest network, allocating a different network segment for it and essentially delving pretty deep into getting things setup how I wanted.  But in the end, the only thing I really needed to do to ensure my Airport environment worked was to alter the modem to bridge mode. If I didn’t have my own router and wanted to use the built in SSID that comes on the modem, which by the way you can rename if you want to, then out of the box my IPv6-capable devices would all have started using IPv6. Where they don’t, they fall back to IPv4, which we all still mostly rely on. I note with interest that my Airport Utility still has a strong focus on IPv4. Although it supports IPv6 transparently, any IP setup option still mostly involves IPv4 addresses. I wonder if that will change over time?


Chris HarveyChris has over 20 years of experience in the computer industry, including software sales engineering, implementation, consulting and solutions architecture. Chris’ career diversity stems from many years as a successful independent consultant, sales engineer, internal and external solutions architect; all within a variety of well respected companies in senior positions providing leadership, mentoring, product or solution delivery.





IPv6-Brewed Coffee Over Bluetooth Smart

Glenn Ruben Bakke explains how Nordic Semiconductor is connecting to the Internet of Things using IPv6 over Bluetooth Smart in everything from keyboards to coffee makers.

Guest blog post by Glenn Ruben Bakke

IOT IPv6 Over Bluetooth Smart

Believe it or not, the day has come when your coffee machine could know what exactly what kind of coffee you like to drink depending on the cup you’re using, the time of day, and a multitude of other factors. Earlier this year, the Nordic Semiconductor team demonstrated a smart coffee machine at CES that brewed coffee over IPv6. But coffee machines aren’t the only place where innovation is possible. As a leader in Bluetooth Smart solutions you will find our chips in products all around your home from wireless keyboards and mouse, TV remote controls all the way through to wirelessly controlled toys. Basically, we are already in a wide range of diverse devices. So, for us, extending those devices connectivity through the internet was the next logical step.

We are a strong advocate and believer that the right long term approach for connecting everything to the Internet is by using open standards. In this way obstructive barriers to cross-platform, device and OS communications will be dissolved.

IPv6 Over Bluetooth Smart

Recently a lot of effort has been made by the Internet Engineering Task Force (IETF) to make the Internet suitable for smaller devices, something that is referred to as 6LoWPAN. Bluetooth Smart Specific adaptations and recommendations for 6LoWPAN are being defined as BLE 6LoWPAN and can be found here.

BLE 6LoWPAN enables compression of IPv6 traffic and optimizations in procedures (for example, neighbor discovery) on Bluetooth Smart. BLE 6LoWPAN defines Stateless Address Autoconfiguration (SLAAC) of IPv6 addresses using the Bluetooth Smart Device Addresses. The 6LoWPAN-enabled Bluetooth Smart device will derive a EUI-64 address based on its own EUI-48 MAC address and this is combined with the assigned prefix to form an IPv6 address.

Stack Diagram

BLE 6LoWPAN defines two roles for Bluetooth Smart devices: the 6LoWPAN node role and 6LoWPAN edge router role. In the 6LoWPAN node role Bluetooth Smart devices can connect to the internet over Bluetooth Smart using a border router. The border router role acts as a device that is connected to the internet and provides access for the nodes to the internet.

6lowpan Roles

IPv6-enabled Coffee Machine

We wanted to demonstrate the exciting possibilities that this technology enables and we wanted to show that by doing something practical. What better way than brewing coffee over IPv6? – not only demonstrating a connected appliance that can be controlled and monitored from the Internet, but also getting a nice cup of coffee at the end of it.

The coffee machine, being IP enabled, has its own IPv6 address which means it is directly addressable from the Internet. Also, native support IP protocols allow the coffee machine and the cloud application to use the same protocol without any need of proxy or translations. The application protocol used in this demo is MQTT, a TCP based protocol.

In this demo you can request a brew through the web interface. You can also see if the coffee machine is brewing or idle, the number of cups brewed etc. – all examples of monitoring a remote appliance.

We used the following hardware components to brew coffee over IPv6:

  1. Coffee machine – connected to the nRF51 Development Kit playing the role of BLE 6LowPAN node role and an MQTT client.
  2. Raspberry PI   – playing the role of BLE 6LoWPAN router providing connectivity to the internet to the coffee machine by routing packets between its Bluetooth and Ethernet network interfaces.
  3. PC symbolizing a cloud server. The PC provides the software infrastructure of the demo.

Coffe Machine Setup

The software pieces we used are:

  1. MQTT broker. MQTT protocol requires a central broker that manages messages between various clients that connect to it. Here, HiveMQ is used as the broker.
  2. Django web server providing an interface to control the coffee machine.
  3. Database is used to store information related to the coffee machine.
  4. A controller module that listens for messages from coffee machines. Any updates or request to the database are handled by this module.

Coffee Web Interface

Routing on Raspberry Pi

Once a 6LoWPAN node connects to the Raspberry PI, a Bluetooth network interface appears on the Raspberry Pi. Routing packets to this Bluetooth Network interface is like routing packets on any network interface. Linux provides a router advertisement daemon, radvd, which is used in this setup.

The radvd is setup to delegate an IPv6 prefix to all the endpoints connecting to the switch so that global IPv6 address can be created on the nodes using State-Less Address Auto-Configuration (SLAAC). The Ethernet interface (eth0) takes care of devices connecting to the simulated global network, and the Bluetooth interface (bt0) takes care of the IPv6/6LoWPAN over Bluetooth Smart devices connection. For Bluetooth, radvd will give each node on the link (bt0) a 2001:def:: prefix, and for Ethernet each node will get a 2003:abc:: prefix using 2003:abc::1 as gateway.


6 radvd config

A route is also put up between the global network (eth0) and the Bluetooth/6LoWPAN network (bt0) that connects the 2001:def:: subnet to 2003:abc:: subnet. This makes the Bluetooth nodes available in the simulated global network.

Routing on Raspberry PI

With this setup each coffee machine can create a TCP connection to the MQTT broker using its global IPv6 address, publish messages and listen to responses or commands.

We were proud to demo our IPv6 coffee machine at CES earlier this year and see it as the first – and major – step of many devices into IoT over IPv6.


Glenn Ruben BakkeGlenn Ruben Bakke is a Software Engineer who has been developing software for Nordic Semiconductor’s nRF51 Series ICs as well as working on the development of the IoT SDK.





The Per Scholas Approach to Bringing IPv6 into the Classroom

Eduardo Hernandez of Per Scholas shows why IPv6 is an essential part of the curriculum for IT students as they prepare for jobs in the tech industry.

Guest blog post by Eduardo Hernandez

I am an instructor at Per Scholas, a national nonprofit organization that provides free technology education, career development and job placement services to unemployed and underemployed individuals throughout Columbus and Cincinnati, OH; Dallas, New York City, and Silver Spring, MD. We take pride in providing comprehensive technical training to individuals with no background in technology, and on average the school trains approximately 800 students a year and 75 percent successfully go on to land jobs in tech.   I take a lead role in making curriculum enhancements and adjustments based on the industry trends (I am also a graduate of the program myself!), and recently we decided to add IPv6 to the curriculum.

Per Scholas Teaching

Despite struggles in adaptation, IPv6 is clearly the future when it comes to finding a solution to the currently depleting addressing space.  It is with this thought that Per Scholas is beginning to roll out changes in our curriculum, which not only embrace IPv6, but successfully train students in becoming proponents and implementers of the addressing scheme.  This means that we are assisting nearly 600 freshly trained students with broad technical skills and new perspectives to enter the IT workforce this year with IPv6 networking skills that employers are looking for.

For those unfamiliar with networking, IPv6 can be overwhelming and exceedingly complex. As educators it is imperative that we approach IPv6 via active student participation. To implement this philosophy my students create an account on at the beginning of my first IPv6 lesson.  SixXs is a free IPv6 tunnel broker.  Once students create an account they may apply for their own tunnel.  Upon tunnel creation students are given their own IPv6 address to a public PoP, along with a range of routable subnets.  The idea behind this approach is that students will go home and do the same procedure on their home networks, thus increasing their knowledge base and preparing for the future of total IPv6 implementation.  Once a student has successfully created a 6-to-4 tunnel on their computer, various other lessons are assigned which further their understanding of IPv6.

Following this preliminary experience with IPv6, we are then ready to tackle the complicated task of IPv6 subnetting.  When it comes to subnetting most educators will agree that it is one of the most difficult concepts for students to understand.  With IPv4, subnetting was necessary, and although with IPv6 it is not required it is still very important for a network technician to know.  Subnetting IPv6 is rather daunting since students need to train their brains into working with hexadecimals.  As practice exercises students work with the subnets given to them from the tunnel broker and apply them in class.  This allows them to see the fruits of their labor.

IPv6 is here to stay! As more and more people get connected to the web, with every device having its own IP address, and the Internet of Things (IOT) becoming a reality, there will be more demand for technicians who can implement IPv6.  The Per Scholas approach is to give students the best tools to succeed in the ever-changing IT world, so that is why we have added IPv6 to our curriculum. It is important that IT educators give the tools necessary for success to their students.  I for one am glad to finally get rid of NAT and the complexities of setting up IPv4 networks.  IPv6 is the future; it is time to embrace it.


Eduardo HernandezEduardo Hernandez is an Associate Director of Technical Instruction at Per Scholas. He began his career there 2 years ago as a student.  He took part in an advanced IT training program called Project Scale.  Upon graduation Eduardo obtained valuable industry certifications: CompTia A+, Security +, and Cisco CCNA certification. Prior to his position at Per Scholas, Eduardo graduated with a Bachelor’s Degree in Computer Science from Pace University and worked as a Network and Security consultant. He also ran a successful after-school tutoring business.

Set Up IPv6 in Your Own Home

Jeremy Duncan, Managing Partner and IPv6 Architect at  Tachyon Dynamics, gives his opinion on some good applications and tunneling providers you can use to get IPv6 in your home if your ISP doesn’t offer it already.

Guest blog post by Jeremy Duncan, Tachyon Dynamics

IPv6 in home or residential networks is getting much better.  North America has seen exponential IPv6 use on the Internet year after year since World IPv6 Launch (6 June 2012).  Residential Internet service providers like Comcast and Time Warner are almost singularly responsible for this sharp and dramatic growth.  However, if you aren’t a Comcast or Time Warner user, it’s a totally different story.  I’m one of those users, and I want to pass on some of the great ways to setup your own IPv6 internet access using one of the great (and free) IPv6 over IPv4 tunnel providers.

Don’t Have IPv6 at Home?

So your ISP is one of any of the minor and major ISPs that have no IPv6 implementation currently.  What can one do?  Do it yourself!  I’ll show you a few applications and tunneling providers to use, as well as ones to never use.

Hurricane Electric

This is probably the best IPv6 in IPv4 tunneling provider out there today. Also, it’s free for small networks. The provisioning is very easy. The graphic below shows how to provision a tunnel and it gives you sample configurations for your gateway of choice. Basically, anything that can do a 6in4 tunnel (IPv4 protocol 41) can use this service. This includes any workstation or server operating system, router, firewall, or custom CPE (e.g. OpenWRT).


Just go to Once there, you can create an account, and select “Create Regular Tunnel.” There it will ask you which PoP you’d like to use and what your public IPv4 source address is. Once you click “apply,” the full configuration screen will be presented and your tunnel is activated and ready to connect. If you aren’t sure how to do tunneling configured you can click “example configurations,” and it will give you the exact CLI configuration needed for your gateway of choice. For example, here is one for a Cisco IOS router:

configure terminal

interface Tunnel0

description Hurricane Electric IPv6 Tunnel Broker

no ip address

ipv6 enable

ipv6 address 2001:db:1:1::2/64

tunnel source

tunnel destination

tunnel mode ipv6ip

ipv6 route ::/0 Tunnel0


Once you have the tunnel up and running, go back into the provisioning page and click “request a routed /48 prefix.” With this prefix you can assign 65,536 /64 network on your home LAN. That will probably be enough for now. :)

Other Hurricane Electric Services:


SixXs is more of a community supported tunneling service. They aren’t backed by a large corporate entity like Hurricane Electric, but still provide a few good tunneling services. They were one of the first 6in4 tunneling providers to the industry.

When you navigate to, sign up for an account. SixXs is very diligent about keeping tunnels up and healthy and are constantly checking on the health. When you have an account you get points for how long your tunnel remains up, and are subtracted points when your tunnel is down. You can cash these points in for /48 prefixes and other little goodies along the way. These incentives keep the overhead of maintaining dead tunnels to a minimum as it is community supported.

Their data rates don’t match Hurricane Electric. I see comparable IPv4 to IPv6 tests with Hurricane Electric, but much slower with SixXs. However, it remains a very good, free, and relevant IPv6 in IPv4 tunneling service. SixXs also provides:

  • Automatic IPv6 Client Utility (AICCU): This is a client-side software application that uses UDP port 5072 to tunnel IPv6 over IPv4 UDP. Certain networks may not allow UDP port 5072 outbound, so use this with care. Details are here:
  • IPv6 website gateway: This URL-based proxy allows you to connect to IPv6 enabled website using an IPv6 domain name. For example, will get you to the IPv6 only Google website, but the SixXs gateways will proxy you using IPv4 to your web browser. Details are here:
  • IPv6 Unique Local Address (ULA) registration site: As per RFC 4193, ULA address must not be routable, but must still be globally unique. This site will use the algorithm to generate globally unique addresses, then will register them so organizations can use them later as bogon lists if needed. Details are here:


GoGo6 was a company that sprang from Hexago. Hexago was the company that created the appliance-based IPv6 tunnel broker. It was an all in one, and easy to deploy, full tunneling solution. The company is called GoGo6 now and it’s product is called GoGoServer. It offers a free service for users to connect using a client application similar to SixXs, but with more tunneling options: 6in4, UDP port 3653, and DS-Lite. More details on this service is here:  That client application configuration looks like this:


GoGo6 also offers the following services:

  • Appliance/CPE for the client-side tunneling called GoGoCPE that is sold for a very small cost:
  • You can register for the free IPv6 social network called GoGoNET. Most of the IPv6 industry professionals are here and able to talk and answer questions. Details are here:
  • GoGo6 also has an annual conference where they bring in industry experts and talk about IPv6 issues of the day called GoGoNET Live. Details for that event is here:

Tunneling You Should Never Do – Ever!

The previous services and providers I mentioned are very good and have a lot of management and oversight around them. However, there are a few services you should never use for the following reasons:


Don’t ever enable this. If your Windows machine is on a Windows domain, whatever you do don’t re-enable it. If you have a home PC, then you need to disable it ASAP! Use the DisabledComponents registry key to do this. Just follow this registry path:


Now in this path create (or edit) the 32-bit DWORD file DisabledComponents with a decimal value of 1. Then reboot your machine. This setting will disable all IPv6 tunneling mechanisms on your machine. This is best practice for all Windows machines unless it is a DirectAccess Server.

So why is Teredo so bad? One word: control. First, the tunneling mechanism uses UDP port 3544 for client-to-server communication. However, that’s not the only port. Once the server assignes the address to the client it then directs the client to a Teredo relay based on Anycast. This means the client could theoretically be pointed to a Teredo relay anywhere in the world. At this point the Teredo-enabled client can get to the IPv6 Internet through the Teredo relay anywhere in the world. That is the bad part. So I recommend never using it, ever.

  • Disable IPv6 tunneling in DisabledComponents
  • Block UDP destination port 3544 and 3545 on your gateway device


Don’t ever enable this either. Regardless if your Windows machine is on a domain or not this function is always enabled. However, it will not configure itself unless it has a public IPv4 address. However, if it does have a public IPv4 address, then the Windows machine does not need a server to configure its address. It uses a 6to4 addressing algorithm as explained in RFC 3056. This algorithm from an IPv4 only client to the IPv6 Internet uses the 6to4 prefix, IPv4 public source address, the subnet ID, and the local IPv4 private address. So it looks something like this: 2002:4A7D:2B63: 5EFE::C0A8:0064

When setting up 6to4 on a local LAN, the subnet ID can be configurable, but Microsoft uses the 5EFE subnet ID. Once it auto configures this address the windows machine will go out to That DNS name resolves to the public IPv4 address of the Anycast 6to4 relay. This machine will then be able to go to the IPv6 Internet. The same security problems remains as with Teredo, it could go anywhere in the world.


  • Disable IPv6 tunneling in DisabledComponents
  • Block protocol 41 on your gateway device


The residential ISPs are doing better. Between Comcast and Time Warner, users mostly likely have IPv6 in their networks. However, others still trail behind. There are many good and free tunneling solutions from Hurricane Electric, SixXS, GoGo6, for home users to try. However, I recommend to never use Teredo and 6to4 for security reasons outlined above. If you have any questions or comments about this blog please don’t hesitate to reach out to me at


Jeremy DuncanJeremy has spent over 10 years working in enterprise IT doing next generation technology deployments like IPv6, advanced networking, and open source solutions.  He participates regularly with the North American IPv6 Task Force; often speaking at the North American IPv6 Summits each year.  Jeremy spent 11 years in the U.S Marine Corps deploying to Iraq twice during Operation Iraqi Freedom 1 and 2 as a Communications and Information Systems Officer.  Jeremy has worked in the DoD with a wide range of information security, network engineering, and network architecture experiences with DISA, JITC, DTRA, and DTIC.  He currently leads up Tachyon Dynamics’ DoD UC APL and IPv6 training and engineering portfolios. He has a Masters of Science in Information Systems and is married with two wonderful children.


8 steps to get your site ready for IPv6

Republished with permission from the Mythic Beasts blog detailing how to get 10/10 on their IPv6 domain readiness checker.

1. Add an IPv6 address to your web server

The first step is to get your web server listening on an IPv6 address, as well as an IPv4 address. How you achieve this will depend on how your web server is managed. If you’re on a shared hosting account, you’ll be dependent on your hosting provider. If you run your own server, you’ll need to obtain an IPv6 address from your hosting provider (assuming they support IPv6), configure your server to use it and then ensure that your web server (e.g. Apache is listening on this address).

2. Add an AAAA record for your website

AAAA records are the IPv6 equivalent of A records, which resolve hostnames to IP addresses.  In order for users to find your website over IPv6, you will need to add an AAAA record for pointing to the IPv6 address configured above.  You can check that this is in place using the dig command:

$ dig +short A

$ dig +short AAAA

It’s possible that your existing “www” record will be a CNAME for another hostname, in which case you should add the AAAA record to that hostname, rather than the “www” record.

Our health checker will skip this test if your domain doesn’t have an A record for “www”.

3. Add an AAAA record for your bare domain

Most websites are configured to work if the user omits the “www” prefix from the name, for example

In order for this to work, you will need an A record for your domain name itself, and to be IPv6-enabled, you’ll also need a corresponding AAAA record.

Once again, our checker will skip this test if the bare domain doesn’t have an A record.

4. Ensure your DNS servers have IPv6 addresses

The steps above make it possible to access your website over IPv6, but unless your DNS servers are accessible over IPv6, users (or more specifically, their DNS resolvers) will still need to use IPv4 in order to find your site in the first place. To avoid this, you need to ensure that your nameservers have IPv6 addresses.

You can find the nameservers for your domain using “whois”, and you can check whether the servers have IPv6 addresses using dig, as before:

$ whois
[ ... ]
Name Server: NS0.BEASTS.ORG
[ ... ]
$ dig +short AAAA

If your nameservers do not have IPv6 addresses, then unless you run your own nameservers, you’ll either need to persuade your hosting provider to enable IPv6, or switch your DNS provider to a different provider.

For a full pass, our health checker requires that at least two of your servers have IPv6 addresses.

5. Add IPv6 glue for your nameservers, if necessary

In order to find the address for your website, a DNS resolver will first need to find the address of your nameservers. If your nameservers are in your own domain, this creates a bootstrapping problem. For example, in order to find the address for, you need to ask the nameservers for, which includes The solution to this is a glue record, a record containing the address of your nameserver which is held by the nameserver for the next zone up. In this case, the next zone up is .com, so the .com nameservers would contain glue records for the ns* nameservers.

If a nameserver has an IPv6 address, then any glue records for it should also contain that IPv6 address.

Checking for glue records is a little bit involved. The quickest way to do it is to use “dig +trace” to find a nameserver for the next zone up:

$ dig +trace
com.      172800  IN  NS
com.      172800  IN  NS
com.      172800  IN  NS

We can now ask any of those servers for the NS records for our domain. Any glue records that exist will be returned in the “additional” section of the response:

$ $ dig NS
;; ADDITIONAL SECTION:  172800  IN  AAAA  2600:3c00::f03c:91ff:fe96:beac  172800  IN  A  172800  IN  AAAA  2a00:1098:0:80:1000::10  172800  IN  A

If your servers are missing glue records, you will need to get your domain registrar to add them.

It’s worth noting that even if you don’t directly require glue because your nameservers are in a different zone, at some point along the chain there will be a nameserver that does require glue.

For a full pass, our glue checker requires at least two nameservers to be discoverable by a single-stack IPv6 resolver at every step of the chain of delegation.

6. Add IPv6 addresses for your incoming mail servers

In order to receive mail over IPv6, at least some of the mail servers listed in the MX records for your domain must have IPv6 addresses. You can find the mail servers for your domain using dig:

$ dig +short MX

You can then check that these servers have IPv6 address by using dig to resolve an AAAA record, as before.

In order to pass this test, at least one of the servers listed in your MX records must have an IPv6 address.

7. Add reverse DNS for your mail servers’ IPv6 address

It is generally advisable to have working reverse DNS for any addresses from which you send outgoing mail. In the case of IPv6, this becomes pretty much essential, as one of the biggest mail providers in the world, Google, will reject mail over IPv6 unless the sending server has working reverse DNS for its IPv6 address.

Unless you run your own mail servers, adding support for IPv6 will be down to your mail provider.

Unfortunately, there is no reliable way to obtain the outgoing mail servers that are used for a particular domain, so instead our health check makes a bold assumption that your outgoing servers are the same as the incoming servers listed in your MX records, and checks those. This assumption is certainly not true of all domains, which is why a failure of this test is only treated as a warning.

8. Check your SPF records

SPF (Sender Policy Framework) is a mechanism for publicly listing your outgoing mail servers, so that receivers can detect spoofed email sent from other servers. If you enable your outgoing mail servers to start sending mail over IPv6, and you have an existing SPF record, it is important that you make sure that it includes the IPv6 addresses for your mailservers.

There are various ways of doing this. If your incoming and outgoing mail servers are the same, then you can use the “mx” mechanism in your SPF record. This means that any hosts listed in the MX records for your domains will be regarded as a legitimate source of mail for your domain, and this will automatically include any IPv6 addresses (assuming you’ve done step 6).

If you list IPv4 addresses or address ranges in your SPF record explicitly, then you will need to add corresponding IPv6 addresses for those servers.

The rules applied by our health checker aren’t entirely trivial, as it’s not uncommon for legitimate third party servers to be included in a domain’s SPF record, and there’s no way of pairing up IPv6 addresses with their IPv4 counter parts. Our health checker applies some very broad rules: if you use the “mx” mechanism, then the checker requires at least one IPv6 address for a server listed in the relevant MX records. If there are any explicit “ip4″ addresses or ranges specified in the record, then the health checker expects to find at least one explicit “ip6″ mechanism.

If your domain does not list an SPF record then this test will pass automatically, as this effectively defaults to “accept from all”.

These rules aren’t watertight, but have proven to be quite effective in identifying mail sources that either haven’t been enabled by IPv6, or which have but haven’t been added to the SPF record.