Turning on IPv6 without surprising a single server

The reason many production networks still run IPv4 only is not technical. It is fear: that switching IPv6 on will change something on servers nobody has looked at in years, or open a door that every IPv4 access list carefully closed. Both fears are reasonable, and both are avoidable with the right order of work. This is the order we use.

The two real risks

Servers configure themselves. Most operating systems will accept router advertisements by default. The moment a gateway on a VLAN starts advertising a prefix, every host on that VLAN may assign itself an IPv6 address, install a default route, and start preferring IPv6 for anything that resolves to a AAAA record. Nobody changed those servers, yet their behaviour changed.

Security policy is per protocol. An IPv4 access list does nothing for IPv6. Management interfaces locked down over IPv4 can be wide open over IPv6 the day a device gets a global address. This is the risk that bites quietly, because nothing is broken; it is just exposed.

Step one: an address plan you will not regret

Before configuring anything, carve the allocation on paper. A plan that has served us well:

• One public block for customer production.
• One public block for platform and internal services that need to be reachable.
• One internal-only block, registered with the RIR but never announced, for management and infrastructure that must never be internet routable.
• Inside each block, mirror the IPv4 plan where you can. If VLAN 210 carries 192.0.2.0/26 in IPv4, give it an obvious, derivable /64 in IPv6. Engineers should be able to work out a host's IPv6 twin without looking it up.

Use a /64 for every LAN segment, and /127 for point-to-point links. Reserve a whole block for loopbacks, so router identities are easy to recognise in traceroutes and logs. Decide early how hosts get addresses: static assignment for servers keeps addresses predictable for firewall rules and reverse DNS, while stateless autoconfiguration suits client networks better than server networks.

Step two: security parity before reachability

Lock the doors before you open the street. On every device, before IPv6 routing reaches it from outside:

• Management access lists for SSH, SNMP, APIs and web interfaces exist for IPv6 and deny the internet, matching the IPv4 ones.
• Anti-spoof filtering is applied to IPv6 on every internet-facing interface, with unicast reverse path checking or explicit source filters.
• Control plane policing covers ICMPv6 and neighbour discovery, so the device stays manageable under a flood, without blocking the neighbour discovery traffic IPv6 needs to work at all. ICMPv6 is not optional in IPv6 the way some treat ICMP in IPv4: packet-too-big messages are how path MTU discovery works.
• Reverse DNS zones for the new space are delegated and populated, so mail and compliance checks do not fail the first time a host speaks IPv6.

Step three: edge to core, one device at a time

Add IPv6 address families to existing BGP sessions with transit and peers rather than building new ones, and work inward: edge routers, then the links toward the fabric, then the fabric's internal routing. Change one device at a time, and snapshot the state of every routing session before and after each step so you can see at a glance that nothing else moved:

show bgp all summary | utility egrep "Neighbor|Estab|Idle|Active"

Saved before and after each change, a simple diff of that output is the fastest regression test you will ever write.

Step four: quiet gateways

Now configure IPv6 gateways where the IPv4 gateways already live, on the same VLANs and leaves, but with router advertisements suppressed:

interface Vlan210
  ipv6 address 2001:db8:210::1/64
  ipv6 nd suppress-ra

Nothing changes for existing servers, because nobody is advertising a prefix to them. Hosts get IPv6 when you decide, either with a static address and gateway in their own configuration, or by enabling advertisements on a VLAN where every host is known and ready. On Linux, check what a host will do before you flip anything:

sysctl net.ipv6.conf.all.accept_ra net.ipv6.conf.eth0.accept_ra
ip -6 addr show; ip -6 route show

Step five: test from outside, over both protocols

The view from inside a network flatters it. Once a block is announced, scan every address on every device from an external vantage point over both IPv4 and IPv6, and confirm that no management, monitoring or routing port answers from the internet. Then do the positive test: reach a real host over IPv6 from several countries with no loss, and confirm that its AAAA record, its reverse record and its TLS certificate all work over IPv6 exactly as they do over IPv4. A service that resolves over IPv6 but does not answer is worse than one without IPv6 at all, because clients will try it first and wait. Tools such as nmap from an outside host, and global measurement networks such as RIPE Atlas, make both checks easy.

nmap -6 -Pn -p 22,161,179,443,830 2001:db8:210::1

Your own checklist

• Is there a written IPv6 plan that mirrors your IPv4 plan?
• Does every IPv4 management restriction have an IPv6 twin?
• Is anti-spoof filtering bound for IPv6 on internet-facing interfaces?
• Are router advertisements suppressed until you choose to enable them?
• Do your IPv6 reverse zones exist and resolve?
• Have you scanned your own IPv6 space from outside?

IPv6 is native at all our sites, Athens, Amsterdam and Toronto, and was rolled out in this order. If you want IPv6 on your platform without surprises, we would be glad to help.

Talk to an engineer

Related: IPv6, native and dual-stack · How we change things: network change discipline · Authoritative DNS and reverse DNS, run as infrastructure