IPv6 Deployment: A Network Admin's Checklist

Deploying IPv6 isn't just about enabling a protocol. It's about planning an addressing scheme that scales, configuring security policies that match your IPv4 rules, and ensuring your monitoring catches problems before users do.

This checklist covers what you actually need to do, based on real deployments. Skip steps at your own risk.

Before You Start #

Take Inventory #

List every device, application, and service that needs network connectivity. Don't assume everything supports IPv6—test it. That legacy printer or SCADA system might be the blocker you didn't expect.

Check your vendor support. OS support is nearly universal now, but proprietary software and embedded systems can lag behind. Know what works and what doesn't before you commit.

Get Your Allocation #

Request IPv6 space from your ISP or Regional Internet Registry. Most ISPs provide at least a /48 to business customers, giving you 65,536 /64 subnets. If you're multihomed or running a datacenter, get your own Provider Independent (PI) allocation.

Don't settle for a /64 unless you're a single-subnet shop. You need room to grow.

Design Your Addressing Scheme #

Plan your addressing before assigning anything. A /48 gives you a 16-bit subnet field—use it wisely. Group subnets by location, function, or security zone.

Example scheme:

2001:db8::/48          Your allocation
2001:db8:0001::/64     HQ office network
2001:db8:0002::/64     HQ server VLAN
2001:db8:0100::/64     Branch office 1
2001:db8:0200::/64     Branch office 2
2001:db8:1000::/64     DMZ web servers

Reserve ranges for future use. Leave gaps. You won't regret having extra space.

Train Your Team #

IPv6 looks different. Hexadecimal notation, address abbreviation rules, and the sheer size of addresses trip people up. Run training sessions. Make sure everyone understands the basics before deployment day.

Cover ICMPv6—it's not optional like ICMP in IPv4. Blocking it breaks neighbor discovery and path MTU discovery.

Address Planning #

Use Full /64 Subnets #

Always allocate /64 for end-user networks. SLAAC requires it, and trying to use /127 or /126 on LANs causes operational headaches. The address space is enormous—use it.

For point-to-point links, /127 is fine and recommended (RFC 6164). It prevents ping-pong attacks and saves a negligible amount of space you don't need to save.

Document Everything #

Start documentation on day one. Record your allocation, subnet assignments, and the logic behind them. Future you—or your replacement—will need this.

Use IPAM tools. Spreadsheets work for small networks, but dedicated tools like NetBox or phpIPAM scale better and reduce errors.

Reserve Space for Growth #

Don't allocate subnets sequentially without planning. Leave room between logical groups. If your office network is 2001:db8:100::/64, don't put the next office at :101::/64. Use :200::/64 and give yourself 256 subnets of breathing room.

Randomize Server Addresses #

Don't number servers sequentially (::1, ::2, ::3). Use random or semantically meaningful addresses within your /64. Sequential addressing makes scanning easier and exposes your network size.

Generate random addresses or use EUI-64, but disable privacy extensions on servers—you want stable addresses for DNS.

DNS Best Practices #

Add AAAA Records for Everything #

Every service with IPv6 connectivity needs an AAAA record. Don't half-deploy by enabling IPv6 but skipping DNS. Clients will try IPv6 first and fail, causing connection delays.

For dual-stack services, publish both A and AAAA. Let Happy Eyeballs (RFC 6555) handle failover.

Configure Reverse DNS #

Set up PTR records in ip6.arpa. Reverse DNS isn't just for mail servers—it's used for logging, security tools, and troubleshooting. Missing PTR records look sloppy and can trigger spam filters.

Delegate your reverse zone properly. If your RIR or ISP handles delegation, submit the records. If you control it, automate updates.

Ensure Dual-Stack Resolvers #

Your DNS resolvers must answer queries over both IPv4 and IPv6. Configure IPv6 transport even if your network isn't fully dual-stack yet. Clients increasingly prefer IPv6 transport for DNS.

Test with dig or nslookup from IPv6-only clients. Don't assume it works.

Test with IPv6-Only Clients #

Spin up a test VM or container with IPv6 only—no IPv4 address. Try accessing your services. You'll find gaps you missed: hardcoded IPv4 addresses, broken AAAA records, or applications that don't handle dual-stack correctly.

Routing Considerations #

Enable IPv6 on All Routers #

Turn on IPv6 routing globally. Even if a segment isn't using IPv6 yet, having it ready prevents rushed configuration later.

Configure link-local addresses on all interfaces. They're required for routing protocols and don't need global addressing.

Choose Your Interior Routing Protocol #

OSPFv3 and IS-IS both support IPv6. If you're running OSPFv2 for IPv4, OSPFv3 is the natural choice. IS-IS handles both address families in a single protocol instance, which simplifies things if you're starting fresh.

Don't run RIPng. It's obsolete and limited.

Configure BGP for External Connectivity #

If you're multihomed, run BGP for IPv6 just like IPv4. Use MP-BGP (Multiprotocol BGP) to carry both address families over one session, or run separate sessions—either works.

Announce your prefix from all upstreams. Configure route filters to prevent leaks.

Filter Bogon Prefixes #

Block reserved and bogon prefixes at your edge. The bogon list is smaller than IPv4 but still necessary. Filter:

::/8 (except ::/128 and ::1/128)
0100::/64 (discard prefix)
2001:db8::/32 (documentation)
fc00::/7 (ULA—block at internet edge)
fe80::/10 (link-local)
ff00::/8 (multicast, context-dependent)

Bogon Filtering

Team Cymru publishes updated bogon lists. Use them to keep your edge filters current and prevent routing table pollution.

Security Best Practices #

Match Firewall Rules to IPv4 Policy #

Your IPv6 firewall policy should mirror IPv4. If you block inbound traffic except specific services in IPv4, do the same for IPv6. Don't leave IPv6 open because it's "new."

Audit carefully. Many firewalls default to permit-all for IPv6 when first enabled.

Allow Essential ICMPv6 #

ICMPv6 is not optional. You must allow:

Type 1 (Destination Unreachable)
Type 2 (Packet Too Big) — breaks PMTUD if blocked
Type 3 (Time Exceeded)
Type 4 (Parameter Problem)
Type 128/129 (Echo Request/Reply) — optional but useful
Type 133-137 (Neighbor Discovery) — on local segments only

Never Block ICMPv6

Blocking ICMPv6 breaks IPv6 connectivity. It's required for neighbor discovery, path MTU discovery, and error reporting. This is not negotiable.

Routing protocol adjacency failures
Unreachable IPv6 gateways
High ICMPv6 error rates
IPv6 traffic drops or blackholing

Don't wait for users to report problems.

Deployment Checklist #

Use this checklist to track your deployment progress:

Deploy methodically. Test thoroughly. Document everything. IPv6 isn't difficult—it's just different.

IPv6 Security Best Practices - Secure your IPv6 network against threats
IPv6 Migration Strategies - Plan and execute your IPv6 deployment

Plan Your Network

Use our Subnet Calculator to design your IPv6 addressing scheme.