IaC practices and the IPv6 transition

Why this matters

Two halves, both from objective 1.8. The first finishes infrastructure as code with the practices that make it survive contact with a real estate. The second covers the IPv6 transition — which is on this exam not as "learn IPv6 addressing" but as "understand the mechanisms that let IPv4 and IPv6 coexist", because coexistence is the state the world has been in for twenty years and will remain in.

This lesson is the domain 1 capstone. It pulls together addressing from lesson 11, the cloud lessons, and the automation ideas from lesson 15.

The lesson

Playbooks, templates and reusable tasks

A playbook (Ansible's term; other tools say manifest, recipe or stack) is the file that describes a desired state and the steps to reach it. A template is a parameterised configuration — one VLAN definition with the number and name left as variables — rendered per device.

Reusable tasks are the units you compose from: "configure NTP", "apply the standard ACL", "set up SNMP". Written once, called from every playbook that needs them.

The point is that the description stops being per-device. One template plus fifty rows of variables produces fifty correct configurations, and a change to the standard is a change in one file.

Most of these tools are declarative and idempotent — you describe the end state rather than the steps, and running the same playbook twice produces the same result rather than doing the work twice. That is what makes it safe to re-run everything routinely, which is how drift gets corrected.

Configuration drift and compliance

Configuration drift is the gradual divergence of a running system from its defined state. Someone makes an emergency change at 3 a.m. and does not put it back. A device is replaced and configured from memory. A temporary rule is never removed.

Drift is dangerous precisely because it is invisible. The network works, so nobody looks — until a failover happens and the backup device behaves differently from the primary, or a rebuild produces a device that is subtly not the one it replaced.

Compliance in this context means checking running configuration against the defined standard and reporting the differences. Automation makes this routine: run the check nightly, report what does not match, and either alert or remediate automatically by re-applying the definition.

The habit that follows: the file is the source of truth, and a change made on the device is a bug, not a change. If the device needs to differ, the file changes first.

Upgrades

Automated upgrades matter for the same reason automated configuration does. Doing a firmware upgrade by hand across a hundred switches is slow, and every one is an opportunity to skip a step.

Automation handles staging images, verifying checksums before installing, rebooting in a controlled order so redundancy is preserved, and confirming the device came back healthy before moving to the next. It also makes rollback a defined procedure rather than an improvisation.

Dynamic inventories

An inventory is the list of devices automation acts on. A static inventory is a file you maintain by hand, and it is wrong the moment something is added or removed — in a cloud environment, possibly within minutes.

A dynamic inventory queries the authoritative source at run time: the cloud provider's API, the IPAM system, the CMDB, the monitoring platform. Devices that exist are included automatically; devices that have gone are not.

The exam framing is autoscaling: instances appear and disappear on their own, so a hand-maintained list cannot describe them, and automation that relies on one will silently skip the instances it does not know about.

Source control, version control and branching

Once infrastructure is files, it belongs in source control — a system that tracks every change, who made it, when and why.

Version control gives you history. Every version is retained, so you can see exactly what changed between a working state and a broken one, and roll back to a known-good definition. "What changed?" stops being a conversation and becomes a diff.

A central repository gives everyone one authoritative copy. No more competing files on individual laptops, and the repository is what automation pulls from, so what runs is what was reviewed.

Branching lets work proceed in parallel. A change is developed on its own branch, reviewed, and merged into the main line when approved — so the main branch always reflects what should be running, while work in progress stays out of the way.

Conflict identification is what happens when two people change the same thing. The system detects the overlap and refuses to merge silently, forcing a human decision. That is the feature, not the annoyance: the alternative is one change quietly overwriting another, which on a network is an outage.

IPv6, and why the transition exists

IPv4 has 32 bits — about 4.3 billion addresses, allocated inefficiently in the classful era and exhausted at the regional registries years ago.

IPv6 has 128 bits, which is 340 undecillion addresses. The practical effect is that address scarcity stops being a design constraint: every device can have a globally unique address, and NAT becomes unnecessary rather than mandatory.

An IPv6 address is eight groups of four hex digits: 2001:0db8:0000:0000:0000:ff00:0042:8329. Two compression rules apply:

• Leading zeros in a group may be dropped: 0db8 → db8.
• One run of consecutive all-zero groups may be replaced by :: — only one, or the address would be ambiguous.

So the above becomes 2001:db8::ff00:42:8329.

Mitigating address exhaustion is the headline reason for IPv6, and it is worth noting that IPv4 survived this long because of mitigations: RFC 1918 private addressing, NAT, and CIDR's efficient allocation. Those bought decades; they did not solve it.

Compatibility: how the two coexist

IPv4 and IPv6 are not interoperable. An IPv6-only host cannot talk to an IPv4-only host without something translating. Since the internet cannot switch over in one night, the transition mechanisms are the practical content, and CompTIA names three.

Dual stack. A device runs both protocols simultaneously, with an IPv4 address and an IPv6 address on the same interface. It talks IPv6 to things that support it and IPv4 to things that do not, choosing per destination — normally preferring IPv6 when a AAAA record exists.

This is the preferred and most common approach because nothing breaks: every destination remains reachable by whichever protocol it speaks. The costs are running two protocol stacks, two sets of firewall rules and two sets of monitoring — and the security trap that IPv6 is often enabled by default and unfiltered, so an estate with a carefully built IPv4 firewall policy can have an entirely open IPv6 path alongside it.

Tunneling. Encapsulate one protocol inside the other to cross a network that does not support it — typically IPv6 packets inside IPv4 so they can traverse an IPv4-only path. Mechanisms include 6to4, Teredo and manually configured GRE tunnels. Useful where you control the endpoints but not the path; it adds overhead and another thing to fail, so it is a bridge rather than a destination.

NAT64. Translation between the two. An IPv6-only client can reach an IPv4-only server: the NAT64 gateway translates the IPv6 packet into IPv4, usually working with DNS64, which synthesises an AAAA record for a destination that only has an A record so the client has something to send to.

This is what makes a genuinely IPv6-only network practical while parts of the internet remain IPv4-only, and it is increasingly how mobile carriers run.

The one-line summary the exam wants: dual stack runs both, tunneling carries one inside the other, NAT64 translates between them.