It has been far too long since my previous post introducing TLNTC. This episode will be a (hopefully!) shorter overview of TLNTC’s journey into IPv6 connectivity.
I don’t know when I started first started to think seriously about learning and implementing IPv6, but probably the earliest defining moment I can remember was Geoff Huston’s LCA2011 keynote in which he explained the IPv4 exhaustion problem, presented it as a problem for openness, and explained the IPv6 solution. I had already done some basic learning on IPv6, but this talk was what got me interested more seriously in making it work. (Huston has seemingly backed away from his earlier position on Internet openness and has become a surprising – at least to me – proponent of IPv4 longevity. I may write more about this later.)
Around this time I started testing IPv6 connectivity for myself, including some transition mechanisms like Hurricane Electric (HE) tunnels and the 6to4 anycast IP 22.214.171.124 (which worked reasonably well at the time, but quickly became irrelevant). At the time I was also studying for my Cisco CCNA, so I had the opportunity to test those things on both Linux and IOS.
A significant step in my tinkering was to move to Internode, one of the earliest ISPs in Australia to make IPv6 available to retail customers. I signed up for a fixed IPv6 allocation on their business plan in mid-2012 and have been with them ever since. Despite a recent IPv6 connectivity problem to AWS which took them far too long (weeks) to resolve, Internode have provided very reliable IPv6 transit for the most part, and I’ve had a static /56 network block allocated to me the whole time.
Moving along with IPv6
A few more interesting waypoints along TLNTC’s IPv6 journey have included:
- In March 2013 there were some great discussions on the AusNOG mailing list, which prompted Mark Newton to write a lovely little post called “IPv6: objections to sale“, along with the skeleton of a plan for how an ISP or application provider might implement IPv6.
- The U.S. government’s Office of Management and Budget (OMB) issued a memo which set two significant deadlines:
Upgrade public/external facing servers and services (e.g. web, email, DNS, ISP services, etc) to operationally use native IPv6 by the end of FY 20121;Transition to IPv6
Upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014;
Even though it was issued in September 2010, this memo didn’t make it onto my radar until some time later; possibly it gained some IT industry press coverage when the 2014 deadline for internal connectivity to Internet IPv6 sites was looming. This was a bit of a wake-up call to me, given that I usually see government initiatives as a sure-fire way to ensure something takes a long time.
Unlike building a new network on IPv4, which usually starts with the core and transitions functionality outwards, transitioning to IPv6 usually involves starting at the edge and working towards the core. The Hurricane Electric IPv6 Sage certification was a great practical tool in this respect: it requires very little knowledge testing, but requires you to demonstrate ownership of various components of a working IPv6 network, which it tests remotely. The tests include: browsing from an IPv6-enabled browser, having an IPv6-enabled web site, having an SMTP server which can accept mail over IPv6, having a DNS server which can be queried over IPv6 for AAAA records, etc. Going through the process of setting up for all of these tests on TLNTC laid a good foundation in getting IPv6 enabled and working on all the edge and core components of the network.
How long should the transition be?
When the work to IPv6-enable the most important parts of TLNTC was complete, I had a functional dual-stack network. But a number of influences made me start asking whether I really wanted the network to stay that way:
- In 2013 Ivan Pepelnjak published a webinar with Tore Anderson, who set up an IPv6-only data centre the previous year, skipping a large number of transition steps.
- In November 2020, the OMB issued M-21-07, which added even stronger mandates to their previous memo:
a. At least 20% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2023;Completing the Transition to Internet Protocol Version 6 (IPv6)
b. At least 50% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2024;
c. At least 80% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2025; and
d. Identify and justify Federal information systems that cannot be converted to use IPv6 and provide a schedule for replacing or retiring these systems;
When I read the mandates in M-21-07 I asked myself, “Why am I not ahead of the U.S. government in my transition? I have a simple, limited-scope network which I fully understand, since I’m the only engineer who has ever worked on it. How many people can say that about their enterprise networks? Surely I could be more nimble than they are?”
The IPv6 Buzz podcast talked about going IPv6-only on your guest wifi. (I think it was in their “Revisiting IPv6-Only” episode, but it might have been in “Our IPv6-Only Future“.) I thought that was a great idea, so I ran up a new VLAN and a new SSID and didn’t let any IPv4 in; it worked surprisingly well on the Android and Windows systems I had at my disposal.
But the real clincher for me was when I started looking at some server upgrades and network design changes and realised that I really disliked maintaining two sets of firewall rules. It was my last round of those firewall edits which really convinced me of the wisdom of Tore Anderson’s approach: the tools already exist for connectivity from an IPv6-only network to an IPv4-only world – why not just implement them now?
So the next few posts in this series will cover the design and implementation choices involved in TLNTC’s transition to an IPv6-only network. Next stop: IPv6 addressing plans!