A kernel patch series titled "Deprecate Legacy IP" was submitted by David Woodhouse:

RFC1883, the IPv6 standard, was published in the final decade of the 1900s. That's closer in time to the Apollo 11 moon landing than it was to today.

Even our esteemed Maddog has worked with computers for longer in the IPv6 era, than he ever did before it.

Yet Linux still can't even be built with only IPv6 support and without support for Legacy IP. This long overdue patch series fixes that, and immediately marks Legacy IP for deprecation.

It also cleans up a few tautological "INET && IPV6" and "INET || IPV6" checks, since IPV6 (and now LEGACY_IP) cannot be selected without the overall CONFIG_INET option.

For now, we only add a warning when a process listens on a Legacy IP socket (since you can listen on IPv6 and still accept connections which have come through a timewarp from the 20th century. Adding warnings for making outbound connections or accepting on Legacy IP can come later.

I would be happy if "Legacy IP" ceased to be the "industry standard" and IPv6 be the default, even if I had to beat IPv6 into the head of every single network administrator's head with a shovel.' said Jon 'maddog' Hall, ancient supporter of Free and Open Source Software.

Also see this follow-up post:

Yeah. The date notwithstanding, I do actually think we should do most of this for real.

Maybe we don't get away with the actual deprecation and the warnings on use just yet, and maybe we won't even get away with calling the config option CONFIG_LEGACY_IP, although I would genuinely like to see us moving consistently towards saying "Legacy IP" instead of "IPv4" everywhere.

But we should clean up the separation of CONFIG_INET and CONFIG_IPV[64] and make it possible to build with either protocol alone.

Fedora 45 (to be released in ~October 2026) will enable IPv6‑mostly networking in NetworkManager by default, automatically recognising DHCPv4 option 108, PREF64 and starting CLAT to provide IPv4 connectivity over an IPv6‑mostly network. This transition eases the shift to IPv6‑only while preserving legacy IPv4 support. No user configuration is required.

ipxlat is a new virtual network device for stateless IPv4/IPv6 packet translation (SIIT, RFC 7915). It is intended as a building block that lets Linux systems support every IPv6↔IPv4 connectivity scenario in RFC 6144. While the core translation is stateless, stateful NAT64 can be added simply with nftables/iptables SNAT or MASQUERADE rules.

The code is based on the Jool out-of-tree kernel module implementation. ipxlat is part of the IPv6 Monostack project

I made this post 3 months ago: https://wetshav.ing/c/ipv6/p/47377/frontier-communications-ipv6-support

I finally got an IPv6 prefix from my ISP (Frontier). Unfortunately they are using /64, so as I'm learning how to handle IPv6 inside my home network I'm finding out that I can't use SLAAC for subnetting.

My next step is to learn about DHCPv6 and succumb to corporate greed. Out of principle, I used the chat function to ask for a /56 and you can imagine the conversation that ensued.

Other comments around the internet are hopeful that since Verizon bought Frontier, and Verizon knows how IPv6 works, there's hope that in the future everyone will get a /56.

NetworkManager now implements CLAT for the 464XLAT transition mechanism, auto‑detecting NAT64 prefixes via PREF64 router advertisements and exposing configurable properties for controlling CLAT behavior. The PR adds two new configuration options: ipv4.clat, defaulting to “no” (for now), and ipv4.dhcp‑ipv6‑only‑preferred, defaulting to “auto”. CLAT is implemented using an eBPF program.

I also posted this at ![email protected] and someone told me about this community.

I've had Frontier fiber internet for the past 2-ish years. No complaints at all, but the nerd in me desires IPv6. I have the Frontier provided ONT device but declined their router. I have a MikroTik RB5009 which has been "searching" for an IPv6 prefix.

Anyway, I found this link during my research some time ago, and it finally looks like Frontier is enabling IPv6 for people.

I'm still not sure I'll be able to get it until I get the settings just right, but thought I'd share.

Source: A manga reader app (Mihon) that sources content (via user-added apps) from various sites (here: WeebCentral.com)

Video creator and IPv6 enthusiast apalrd's adventures - @[email protected] - is planning to lead a renewed effort continuing development of the NAT64 translator tayga.
He also made a video comparing different existing open source solutions and demoing tayga on YouTube: https://www.youtube.com/watch?v=WlQH8KubgiA

With the IPv6-only option, a host can indicate that it supports operation in an IPv6-only network. This is useful in combination with 464XLAT CLAT: IPv4 applications can connect to legacy addresses using a NAT64 gateway provided by the network. In this situation, the host can operate without IPv4 addresses assigned, and all network traffic is IPv6, without loosing connectivity to IPv4 hosts.

NetworkManager currently does not support CLAT, and thus, this new option is disabled by default. Various CLAT implementations exist (jool – out-of-mainline kernel module, upstreaming not planned; tayga – unmaintained userspace application, potentially performance issues), but are not suitable as a general solution.

An eBPF-based CLAT is already being worked on. Hopefully, we can see full IPv6-only support soon! This will enable IPv6-only home networks for the average user, assuming the ISP provides a NAT64 gateway. Connections to IPv4 hosts can be established using the NAT64 gateway, without any IPv4 connections in the local network or directly to the internet. For legacy devices in the local network, IPv6-mostly networks still provide local IPv4 connections.

2001:db8::/32

3fff::/20

cheering on the poor graph :)

https://news.ycombinator.com/item?id=39099065

Im interested in thoughts for a scenario where you want to do small-scale multi-site activities, with site-to-site connectivity.

Here's a couple of constraints:

• you're not going to pay the money to get an assignment, you'll just have ISP global.

• your two or more sites will have different ISPs.

• You're doing VPN between sites instead of provider managed. The sites might be running some normal enterprise services like active directory, or other internal corporate norms.

• you might have the need for a backup Internet connection. Load balancing would not be required.

With the fact that the globals could change at a site, would you consider using ULA? Or just stick with global and update DNS in the event of change. I know there's a preference problem with ipv4 being chosen over ULA, so the ULA thing wouldn't be very easy unless you went straight v6.

If ULA, would you pattern/convention match the global in each site or create one organization wide ULA and assign it something like /48 per site?

What precautions do you take on gateways to ensure globals aren't used outside of the tunnel? ULA prevents this, but so does proper configuration I assume.

How would you do this?

I keep asking about ULA because I heard/read enough articles where the author says don't do it, but they seem to be geared at large enterprise or hosting where they would definitely get dedicated blocks, peering, etc. I'm interested in the little guy.

TIL that apparently capital one was assigned the entire 2630::/16 block...which is the largest assignment I've seen to date. Does anyone know of other absolutely massive allocations...are there even any others this large?

I've been using duckduckgo for years ever since I degoogled but I'm increasingly annoyed by its complete lack of IPv6 connectivity. I use NAT64 and so it works fine but it bothers me to use services that don't have v6. Does someone have a good non-google IPv6 search engine that's privacy respecting?

The only other example I'm aware of is dns.nic.in with 2409::