ConfigureHow

IPv6 at home: what changes and what to do about it

Published . 8 min read

Two things change when IPv6 reaches a home network, and only one is visible. Every device gets its own globally routable address instead of sharing one public IPv4 address behind NAT, and the translation step in the middle of every connection goes away. Neither means your laptop starts listening to the internet, and most reasons given for turning IPv6 off describe problems the standards wrote out of existence.

The address got longer, and that is the whole point

RFC 8200 (July 2017), published as STD 86, is the current Internet Standard and sets the size: IPv6 "increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler autoconfiguration of addresses." The written form is still RFC 4291 (February 2006), amended by six later RFCs but never replaced: eight 16-bit pieces of one to four hex digits, with :: collapsing the longest run of zero groups.

What a household gets is in RFC 6177 (March 2011, BCP 157), which retired the flat /48-per-site advice. It sets a floor: end sites must get "at least one /64, and in most cases significantly more." It names what it exists to prevent, "having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation," and points at "a default assignment of less than /48, such as a /56." A /56 is 256 separate /64 subnets for one household, so the scarcity NAT exists to work around is simply absent.

Where the 128 bits of a home IPv6 address go Two delegation sizes drawn on one 128-bit scale. With the RFC 6177 floor of a single /64, the first 64 bits are the prefix delegated by the ISP and the last 64 bits are the interface identifier, so no bits are left over to subnet with. With a /56, the assignment RFC 6177 points at, the prefix takes 56 bits and the next 8 bits belong to the household, which is 256 separate /64 subnets. The interface identifier stays 64 bits either way, and since RFC 8064 in 2017 it is a stable opaque value rather than the MAC address. One /64 RFC 6177 floor no subnet bits delegated prefix, 64 bits interface identifier, 64 bits 8 subnet bits: 256 separate /64 subnets A /56 RFC 6177 example delegated prefix, 56 bits interface identifier, 64 bits bit 0 56 64 bit 128 Eight 16-bit pieces of one to four hex digits; :: collapses the longest run of zero groups. Since RFC 8064 in 2017 the interface identifier is a stable opaque value, not the MAC address. With 256 subnets in one household, the scarcity that NAT works around is simply absent.
The 64-bit split is fixed, so the only thing a larger delegation buys you is subnets: a /64 leaves none, a /56 leaves eight bits worth.

NAT does not come along for the ride

The IETF's position appears inside the very document specifying prefix translation for IPv6. RFC 6296 (June 2011, Experimental) states in its introduction: "For reasons discussed in [RFC2993] and Section 5, the IETF does not recommend the use of Network Address Translation technology for IPv6." Four years earlier RFC 4864 had put the design intent plainly: IPv6 "was designed with the intention of making NAT unnecessary".

The pressure that keeps IPv4 NAT alive is a price. APNIC chief scientist Geoff Huston's 20 January 2026 review of 2025 records "a mean of USD 22 per address in the most recent 40 days (up to 10 January 2026)" and that "the average price per address has dropped by 50% across 2025." The registries have little left: ARIN 66,560 addresses available, the RIPE NCC 1,536, APNIC 3,107,392. AWS lists an "Hourly charge for In-use Public IPv4 Address" of $0.005, introduced on 1 February 2024 because "the cost to acquire a single public IPv4 address has risen more than 300% over the past 5 years." None of that applies to IPv6.

What replaces port forwarding is a firewall permit rather than a rewrite. The device already holds the address the outside world would use, so nothing needs translating; something just has to stop dropping the packet. Port Control Protocol (RFC 6887, April 2013) standardized asking for that: it lets a host "control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall".

Dual stack, DS-Lite and CGNAT are not interchangeable

RFC 6888 (April 2013, BCP 127) defines carrier-grade NAT as "A NAT-based logical function used to share the same IPv4 address among several subscribers," and adds: "A CGN is not managed by the subscribers." RFC 6333 (August 2011) describes DS-Lite as combining "IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT)," so IPv4 travels inside an IPv6 tunnel rather than beside it. On mobile the pattern is 464XLAT (RFC 6877), "providing limited IPv4 connectivity across an IPv6-only network".

RFC 6598 (April 2012, BCP 153) reserved 100.64.0.0/10 as shared address space for "the interfaces that connect CGN devices to Customer Premises Equipment (CPE)". A WAN address between 100.64.0.0 and 100.127.255.255 on your router's status page means the carrier is translating for you.

Line typeWAN sideInbound IPv4Effect of disabling IPv6
Dual stackPublic IPv4 plus IPv6 prefixWorks if you allow itLoses IPv6 only
CGNAT plus IPv6IPv4 in 100.64.0.0/10, plus IPv6Not possibleRemoves your only inbound path
DS-LiteIPv6 only, IPv4 tunneled to the CGNNot possibleBreaks IPv4 too
464XLAT (mobile)IPv6, IPv4 by translationNot possibleBreaks IPv4 apps

The last column is the part people get wrong: on a dual-stack line it costs you IPv6, on DS-Lite it costs you both.

Routable is not the same as reachable

RFC 6092 (January 2011) describes what a residential IPv6 gateway should do out of the box. Requirement REC-34: "By DEFAULT, a gateway MUST respond with an ICMPv6 'Destination Unreachable' error code 1 (Communication with destination administratively prohibited) to any unsolicited inbound SYN packet after waiting at least 6 seconds without first forwarding the associated outbound SYN or SYN/ACK from the interior peer." That is the outcome IPv4 NAT produced as a side effect, reached deliberately through stateful filtering.

Why a routable IPv6 address is still not a reachable one Three paths between a device and the internet through the same home router. When the device starts the connection the packets pass out and the reply is allowed back, because the router holds the flow in its state table. An unsolicited inbound connection is stopped at the router by default under RFC 6092, which answers with an ICMPv6 Destination Unreachable code 1 after waiting at least 6 seconds, so it never reaches the device. When you add a permit the same packets pass through to the device, and because the device already holds the address the sender used, nothing is rewritten on the way. You start the connection allowed out, reply allowed back Your device Your router Internet The reply comes back because the router already has that flow in its state table. Unsolicited inbound the RFC 6092 default: stopped at the router Your device Your router Internet Answered with ICMPv6 Destination Unreachable code 1, after waiting at least 6 seconds. After you permit it a firewall permit, not a translation Your device Your router Internet The device already holds the address the outside world uses, so nothing is rewritten. RFC 7084 only says a home router SHOULD support RFC 6092, and takes no position on the default. Port Control Protocol (RFC 6887) is the standard way for a host to ask for that permit.
The address never changes across the three cases; only the router's decision does, which is why the fix for an unreachable service is a permit rather than a forward.

There is a catch. RFC 7084 (November 2013) is what consumer edge routers are actually built against, and its requirement S-1 asks only that "The IPv6 CE router SHOULD support [RFC6092]", before closing: "This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure it." Default-deny is a vendor decision, not a protocol guarantee. Some firmware is explicit: OpenWrt's stock wan zone sets option input 'REJECT' and option forward 'REJECT' across option network 'wan wan6', one policy for both families. Yours may not. Find the setting, usually called "IPv6 firewall" or "IPv6 simple security", and read what it opens: some ISP gateways offer a per-device toggle that exposes every port on that device.

RFC 4193 defines Unique Local Addresses in fc00::/7, which "are not expected to be routable on the global Internet," and lists among their benefits that "Sites can change their provider-based IPv6 unicast address without disrupting any communication that uses Local IPv6 addresses." A hardcoded NAS mount pointed at a ULA survives your ISP re-delegating your prefix; one pointed at a global address does not.

The back half of your address stopped being your MAC in 2017

Any explanation that says the interface identifier comes from your MAC address describes pre-2017 behavior. RFC 8064 (February 2017) changed the recommended default for all SLAAC addresses, not only the rotating ones, updating fourteen RFCs including RFC 4291: "By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID," and "Nodes SHOULD implement and employ [RFC7217] as the default scheme for generating stable IPv6 addresses with SLAAC."

RFC 7217 gives the reasoning: EUI-64 identifiers "do not vary over time" and are "constant across networks," so the resulting addresses could be used to "track and correlate the activity of a host across multiple networks".

Temporary addresses are a separate mechanism stacked on top. RFC 4941 (September 2007) is obsolete; the current specification is RFC 8981 (February 2021), and one default moved: both set TEMP_PREFERRED_LIFETIME to "1 day," but TEMP_VALID_LIFETIME dropped from "1 week" to "2 days."

What a given machine does with this is per-platform, and vendor documentation is thinner than you would expect. Microsoft's Set-NetIPv6Protocol reference documents RandomizeIdentifiers as defaulting to "Enabled" while stating no default at all for UseTemporaryAddresses. NetworkManager's ipv6.ip6-privacy falls through to the kernel's use_tempaddr when unset, and distributions set that differently; that page still cites RFC 4941 and still calls the stable address "generated from MAC address via modified EUI-64," nine years after RFC 8064 advised against exactly that. Check the interface, not the folklore: ip -6 addr on Linux, Get-NetIPv6Protocol on Windows.

Where disabling IPv6 is the wrong fix

Microsoft's troubleshooting page, updated 19 February 2026, is the clearest vendor statement available. IPv6 "is a mandatory part of Windows Vista and Windows Server 2008 and newer versions," and "We don't recommend that you disable IPv6 or IPv6 components or unbind IPv6 from interfaces. If you do, some Windows components might not function." The switch also does less than people assume: "You cannot completely disable IPv6 as IPv6 is used internally on the system for many TCPIP tasks. For example, you will still be able to run ping ::1 after configuring this setting." The page links case histories of the attempt breaking LDAP over UDP 389 on domain controllers, Exchange Server 2010, and failover clusters.

Slow browsing is the folk complaint that has aged worst. The problem was real, a client stalling on a broken IPv6 path before falling back to IPv4, and Happy Eyeballs v2 (RFC 8305, December 2017) was written to remove it on the premise that "clients that attempt multiple connections in parallel have a chance of establishing a connection more quickly." That is over eight years old, with a successor in progress (draft-ietf-happy-happyeyeballs-v3, dated 2 July 2026). Clients still differ, so measure yours before blaming the protocol.

Smart-home gear fails quietly. Thread, the mesh radio layer under many Matter products, is headed "OPEN IPv6 BASED PROTOCOL" on the Thread Group's own site. Whether a given hub tolerates an IPv6-free LAN is product-by-product, but that is not what these devices were built for, and the symptom looks like flaky hardware rather than a network setting.

The one case with merit is a VPN client that tunnels only IPv4 on a dual-stack host, leaving native IPv6 on the direct path. That fix belongs in the VPN client, not the network stack. If an application genuinely only works over IPv4, the lever is address selection, governed by RFC 6724 (September 2012). Microsoft recommends "using Prefer IPv4 over IPv6 in prefix policies instead of disabling IPV6," meaning DisabledComponents value 0x20 rather than 0xFF, and shows how easily the blunt route goes wrong: "system startup will be delayed for five seconds if IPv6 is disabled by incorrectly, setting the DisabledComponents registry setting to a value of 0xffffffff. The correct value should be 0xff." That page still cites RFC 3484, superseded by RFC 6724 in 2012, which is a fair measure of how much IPv6 advice in circulation is a decade out of date.

Sources