Infrastructure as Code and IPv6
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
Imagine managing a city's water infrastructure where every single valve, pipe, and pressure gauge must be manually adjusted by hand, one at a time, every time demand shifts. For decades, network administration operated exactly this way, relying on technicians typing commands into individual switch and router consoles late into the night. Today, the sheer scale of modern environments has rendered this artisanal approach impossible. We have transitioned from hand-crafting networks to manufacturing them. Concurrently, the actual "real estate" of the internet has run out of addresses, forcing a fundamental upgrade to the protocol that routes our traffic. Mastering modern network operations requires understanding two massive shifts: how we automate the deployment of infrastructure, and how we implement the vast, practically inexhaustible address space of the next-generation Internet Protocol.

To understand Infrastructure as Code (IaC), we must look at what it replaces. In traditional networking, a system administrator logs into a device, enters an interactive command-line interface, and executes commands one by one to configure a VLAN, set up a routing protocol, or apply an access control list.

Infrastructure as Code involves managing and provisioning computing infrastructure through machine-readable definition files. By defining our network state in text files, Infrastructure as Code eliminates the need for manual hardware configuration or interactive configuration tools. The network becomes a software project.
Instead of typing commands into a live system and hoping you do not make a typo, you declare what you want the network to look like. The automation engine then makes it happen.
Playbooks and Templates
When you need to deploy an update to fifty firewalls, you do not write fifty separate instruction manuals. You use modular code.
- Playbooks: A playbook in Infrastructure as Code is a file containing a series of automated tasks to be executed on a target network device. Think of it as a recipe. If a NOC analyst needs to push out a critical security patch, the playbook instructs the system exactly how to connect, authenticate, execute the update, and verify the result. Infrastructure as Code playbooks are typically written in human-readable data serialization languages like YAML. Because YAML relies on strict indentation and simple key-value pairs, a technician can read it almost like plain English.
- Templates: If a playbook is the recipe, a template is the mold. An Infrastructure as Code template is a standardized blueprint used to deploy consistent infrastructure configurations across multiple environments. When you bring a new branch office online, you do not design its network from scratch; you pass the branch's specific variables (like its IP subnet) into your standard template, ensuring every location is configured identically.
Dynamic Inventories
In the past, network support technicians kept track of active devices using massive, rapidly outdated spreadsheets. Automation requires absolute accuracy. If an automation script attempts to configure a switch that was decommissioned yesterday, the script fails.
To solve this, modern automation uses dynamic inventories, which automatically discover and update the list of network devices available for configuration management. Instead of relying on a static text file, dynamic inventories retrieve real-time host information from cloud providers or management platforms. As virtual routers spin up or physical switches are taken offline, the inventory adjusts dynamically, ensuring your playbooks only target active devices.
Once your network configuration is written as code, you must protect that code. If you make a mistake in a YAML file, you could accidentally bring down the entire datacenter. This is where version control becomes the foundational safety net for IT generalists and system administrators.
Version control is the practice of tracking and managing changes to software code or infrastructure configuration files over time.
At its core, a version control system (like Git) acts as a time machine. It allows network administrators to roll back infrastructure configurations to previous functional states. If a Friday night firewall update inadvertently blocks DNS traffic, the analyst does not need to spend hours troubleshooting; they simply revert to the configuration state from Friday morning.
To manage this across a team, administrators rely on a central repository. This is a unified storage location where all versions of source code and configuration files are maintained. It serves as the "single source of truth" for the entire IT department.
Branching, Committing, and Merging
Working in a live central repository is dangerous. To experiment without risk, we use a concept called branching.
Branching in version control allows an administrator to duplicate a configuration file to safely test changes. When you create a branch, you are effectively working in a parallel universe. Changes made in a version control branch do not affect the main production codebase until the branch is explicitly merged.
The workflow of a modern network engineer looks like this:
- Branch: You pull a copy of the main configuration to work on a new QoS (Quality of Service) policy.
- Commit: As you refine the code, you save your progress. A commit in version control saves a snapshot of the current configuration file changes to the local repository. It acts as a checkpoint, complete with a timestamp and a note explaining the change.
- Merge: Once the QoS policy is tested and verified, you bring it back to reality. A merge in version control integrates changes from a separate branch back into the main configuration codebase, updating the central repository for everyone.

While automation revolutionizes how we build networks, the protocol underlying those networks has undergone its own massive evolution.
For decades, the internet ran entirely on Internet Protocol version 4 (IPv4), which uses a 32-bit address space yielding about 4.3 billion unique IP addresses. By the late 2010s, with the explosion of smartphones and IoT devices, those addresses practically ran out.

The Internet Protocol version 6 (IPv6) was developed specifically to mitigate the exhaustion of available public Internet Protocol version 4 addresses.
To achieve this, the Internet Protocol version 6 uses a 128-bit address space. The mathematical difference between 32 bits and 128 bits is staggering. Instead of 4.3 billion addresses, the Internet Protocol version 6 provides approximately 340 undecillion unique network addresses. To put that in perspective, 340 undecillion (3.4×1038) is enough to assign a unique IP address to every atom on the surface of the Earth, with plenty left over.
We cannot simply turn off IPv4 on a Tuesday and turn on IPv6 on a Wednesday. The internet is a living machine. Therefore, network administrators must use specific transition mechanisms to allow these two incompatible protocols to coexist.
There are three primary strategies for handling this transition: Dual-stack, Tunneling, and Translation.
1. Dual-Stack Routing (The Bilingual Node)
The cleanest, though most resource-intensive, approach is to speak both languages. Dual-stack routing requires a network device to run both the Internet Protocol version 4 and Internet Protocol version 6 protocol stacks simultaneously.
Because it operates both stacks, a dual-stack network node can communicate using either Internet Protocol version 4 or Internet Protocol version 6 natively without relying on translation mechanisms. If a user requests a website that only supports IPv4, the node uses its IPv4 address. If the target supports IPv6, it prioritizes the IPv6 connection.
2. Tunneling (The Envelope Method)
What happens if you have an isolated modern IPv6 network in a branch office, but the internet service provider connecting it to your headquarters only supports legacy IPv4 routing? You use a tunnel.
Internet Protocol version 6 tunneling encapsulates Internet Protocol version 6 packets inside Internet Protocol version 4 packets. Imagine taking a letter written in IPv6, folding it up, and placing it inside a standard IPv4 envelope. The legacy routers in the middle only look at the outside envelope, successfully routing the packet to its destination where the outer IPv4 envelope is stripped away. This mechanism allows isolated Internet Protocol version 6 networks to communicate across a legacy Internet Protocol version 4 infrastructure.

There are several specific tunneling protocols you will encounter in network operations:
- 6to4: This is a fundamental internet transition mechanism that transmits Internet Protocol version 6 packets over an Internet Protocol version 4 network.
- Teredo: Because standard tunneling often breaks when passing through traditional Network Address Translation (NAT) devices, Teredo is a tunneling protocol that encapsulates Internet Protocol version 6 packets within Internet Protocol version 4 User Datagram Protocol (UDP) packets. By wrapping the payload in UDP, it easily traverses standard NAT firewalls.
- ISATAP: The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is used to transmit Internet Protocol version 6 packets between dual-stack nodes on top of an Internet Protocol version 4 network. Note the key term Intra-Site; ISATAP is designed for routing within a private corporate network rather than across the global public internet.
3. Translation: NAT64 (The Interpreter)
Sometimes encapsulation is not enough. You may have a modern data center server running only IPv6, and it needs to serve a client on a legacy mobile phone that runs only IPv4. Because they speak completely different protocols, they cannot communicate directly without an interpreter.
NAT64 is a network address translation mechanism that converts Internet Protocol version 6 packets into Internet Protocol version 4 packets (and vice versa). By intercepting and rewriting the packet headers, NAT64 enables a network node running only Internet Protocol version 6 to communicate directly with a network node running only Internet Protocol version 4.

To achieve this, the system relies on a middleman. A NAT64 gateway requires at least one dedicated Internet Protocol version 4 address to perform translation for internal Internet Protocol version 6 nodes. It dynamically maps the internal IPv6 addresses to its public IPv4 address, much like traditional NAT masks internal private IP addresses today.
By combining Infrastructure as Code to automate highly consistent deployments with a deep understanding of IPv6 addressing and transition techniques, a modern NOC analyst transitions from reacting to the network to effectively orchestrating it.