IPv6 at home: what the longer address changes—and what it doesn’t

IPv6 is not a second internet

An IPv6 address can look alarming at first: 2001:db8:4a2:7::42 has colons, hexadecimal characters, and far more digits than the familiar 192.0.2.42. But it answers the same basic question as IPv4: where should a packet go? IPv6 is the successor version of the Internet Protocol, not a new kind of website, a faster Wi-Fi plan, or a replacement for your router.

The important design change is address size. IPv4 uses 32-bit addresses; IPv6 uses 128-bit addresses. The IETF designed IPv6 with a much larger address space, hierarchy, and easier automatic configuration in mind. That abundance helps networks give devices distinct addresses without the constant scarcity that shaped IPv4 networking.

For ordinary browsing, this should be invisible. A phone or computer asks DNS for a site, then uses the available route—IPv6, IPv4, or both. A site that works well does not need visitors to know which version carried the connection. The longer address is infrastructure, not a new user interface.

Why IPv4 is still beside it

The internet cannot switch protocols in one synchronized moment. Homes, mobile networks, cloud platforms, game servers, and old devices change on their own schedules. That is why the most common transition model is dual stack: a device or service operates with both IPv4 and IPv6, choosing the path that works for the destination.

Dual stack is not a compatibility failure. It is a practical bridge. An IPv6-capable laptop can reach a modern site over IPv6 while still reaching an IPv4-only printer, game server, or older service over IPv4. A small server owner can likewise publish an AAAA DNS record for IPv6 while retaining an A record for players and networks that still need IPv4.

This also explains why an IPv6 connection does not make an IPv4 address disappear. Many residential connections use IPv4 address sharing, commonly called NAT, because public IPv4 addresses are limited. IPv6 reduces the need for that particular workaround, but both protocols remain useful until the systems a household depends on can communicate reliably over IPv6.

• An A record points a name to an IPv4 address; an AAAA record points it to an IPv6 address.
• Dual stack means supporting both protocols, not converting one address into the other.
• If a service needs to reach everyone today, keep both paths tested rather than assuming one path is enough.

Read an address by its job, not by its length

Not every IPv6 address is meant for the public internet. The address alone does not tell you that a device is safely reachable from outside your home. IANA maintains a special-purpose registry that records how important address blocks are intended to behave, including whether they are globally reachable or forwardable.

For example, ::1 is the local loopback address: it means ‘this device’ in IPv6, much like 127.0.0.1 in IPv4. Addresses beginning with fe80:: are link-local. They work only on the immediate local network link and are commonly used for nearby discovery and routing. They are not a public address that someone across the internet can dial directly.

Addresses in fc00::/7 are unique-local addresses. They are useful for internal organization, but they are not a substitute for a globally routed public address. By contrast, global unicast allocations come from the wider IPv6 address space and may be routable on the internet—but ‘may’ matters. The network provider’s routing and the firewall policy still decide what traffic can arrive.

The compressed notation is merely a shortcut. Consecutive zero groups can be replaced once with ::, which is why a compact address and a much longer-looking address can identify the same destination. You do not need to expand it by hand to administer a network. What matters is whether it is loopback, link-local, private-use, or global—and whether a service should accept traffic there.

NAT was never the security boundary

A common IPv4 habit is to treat address sharing as if it were a firewall. NAT often blocks unsolicited inbound connections as a side effect, so it can feel protective. But its main job is translating and sharing addresses, not deciding which applications deserve network access. The real control should be a stateful firewall with explicit rules.

That distinction matters more when a home receives a public IPv6 prefix. Devices can have globally unique addresses, so an accidental ‘allow all inbound’ rule could expose a service without any port-forwarding screen ever being used. A well-configured home router normally blocks unsolicited inbound traffic by default, but ‘normally’ is not a substitute for checking the rule set when you expose something deliberately.

The safe rule is protocol-neutral: allow only the service and port you intend to publish, keep remote management private, and leave everything else denied from the internet. If you host a Minecraft server, its player port is a deliberate exception; SSH, database ports, router administration, and game-management interfaces are not. Apply the same narrow rules to IPv4 and IPv6. Protecting one stack while forgetting the other creates an avoidable blind spot.

A small-server IPv6 checklist

Start with observation, not a network-wide switch. Check whether the server has an IPv6 address and default route, whether its DNS name has an AAAA record, and whether the intended application is listening on IPv6 as well as IPv4. A service bound only to 127.0.0.1 will not magically become reachable over IPv6; a service bound broadly still needs a firewall rule.

Then test from an appropriate outside network. A local test proves that the process is running, but it cannot prove global reachability. Test the exact hostname and application protocol, record the result, and keep the IPv4 path available while you diagnose any IPv6 issue. Do not solve a failed test by disabling the firewall or publishing management ports.

Finally, document the intended shape. A simple note can state which hostname has A and AAAA records, which ports are public, who manages the firewall, and how to roll back a DNS change. That is more useful than a collection of copied commands because it lets the next maintenance session distinguish an intentional public game port from an accidental exposed service.

• Use both A and AAAA records when the service must support IPv4 and IPv6 clients.
• Review inbound firewall rules separately for IPv4 and IPv6.
• Expose a game or web port only when the service is patched, authenticated where appropriate, and monitored.
• Keep administration on a private path; IPv6 does not make public management safer.
• Retest after router, firewall, DNS, or server changes.

The useful mental model

IPv6 is best understood as additional addressing capacity with a cleaner path for modern networks, not as a security product or an upgrade every user has to manage manually. In a healthy setup, DNS and dual stack hide most of the transition. When you run a service, the responsibility is equally ordinary: know which addresses and ports are public, keep both protocol paths covered by the same security policy, and verify changes from outside your network.

That mindset prevents two opposite mistakes. One is avoiding IPv6 because the notation looks unfamiliar. The other is enabling it and assuming the old IPv4 firewall habits will carry over automatically. Treat it as part of the same network, with the same discipline around least exposure and tested configuration, and the longer address becomes just another useful tool.