IPv6 Readiness Checklist for a Self-Hosted Home Server

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

IPv6 Readiness Checklist for a Self-Hosted Home Server - Zima Store Online

The safe approach is to treat a dual-stack readiness review that verifies addressing, filtering, DNS, application identity, and external reachability independently as a sequence of observable gates, not a single command.

On a dual-stack self-hosted home server and router, the practical risk is enabling IPv6 may create a working outbound path while DNS, inbound filtering, and remote application behavior remain unverified. Record the current identity and recovery point, start with the least invasive discriminator, interpret pass and fail results before changing another variable, and stop when storage becomes unstable or the only recoverable copy would be exposed. The workflow below ends only after the original workload succeeds or the evidence reaches an escalation boundary.

Inventory addresses, prefixes, and service bindings

Record the ISP-delegated prefix, router LAN prefixes, server global and link-local addresses, address lifetimes, default route, DNS resolvers, and whether privacy or stable addressing is used. Identify which address will remain suitable for a server across renewals rather than publishing a temporary client address.

Inspect listening sockets for IPv4 and IPv6 separately. A service bound to :: may accept IPv6 on interfaces that were never reachable through IPv4 port forwarding, while an IPv4-only bind can make a healthy IPv6 route look like an application failure.

Use the ZimaSpace exposure workflow on home server exposure check as the adjacent safety gate. Do not publish AAAA records or open inbound rules until each listening process, proxy route, certificate name, and authentication boundary has an owner.

Verify router and host firewall parity

Review stateful inbound policy on the router, host, hypervisor, and container publishing layer. Start with unsolicited inbound denied, then create narrow source, destination, protocol, and port exceptions only for services that must be public or reachable from a trusted VPN prefix.

Global addressing does not require global reachability. The Internet Society stateful IPv6 firewall boundary notes that an IPv6 firewall can allow outbound communications while filtering unsolicited inbound traffic, which is the boundary many users mistakenly attribute to NAT itself.

Test from an external IPv6 network, not from the same LAN. Confirm intended HTTPS works and administrative, database, SMB, and unused ports remain closed or filtered; repeat against both the server address and any public proxy address.

Validate DNS, TLS, routing, and packet size

Query A and AAAA records from internal, external, and VPN clients, then record which address the application actually uses. Ensure the AAAA destination presents the correct certificate and routes the hostname to the same application identity as IPv4.

Test ordinary requests and a larger transfer over IPv6. ICMPv6 Packet Too Big messages are part of path operation, so broad ICMPv6 blocking can create a path-MTU black hole even when small pages load; allow required control traffic rather than treating all ICMP as optional.

Compare logs and behavior by address family. If IPv6 fails while IPv4 works, keep the AAAA record unpublished or lower its scope until routing, firewall, DNS, and proxy evidence identify the difference.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Run failure and persistence tests before release

Restart the router connection or renew the prefix within a maintenance window, then confirm server addressing, dynamic DNS if used, firewall objects, and proxy bindings update as designed. Reboot the server and verify rules load before public services start.

Test loss of IPv6 while IPv4 remains, and loss of IPv4 while IPv6 remains. Clients should fail over predictably or expose a clear dependency; a dual-stack label is not useful if one family silently reaches a different service or stale address.

Declare readiness only when intended services work externally over IPv6, unintended ports remain blocked, DNS and TLS agree, and a prefix change does not bypass policy. Roll back AAAA publication first when results diverge, then preserve packet and firewall evidence for correction.