IPv6

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 !networking@sh.itjust.works 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 - @apalrd@hachyderm.io - 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

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::

Since I moved my server to ipv6 only federation broke. I'm guessing this server is acessible trough the cloudflare proxy, but the underlying server is unable to connect to mine

Edit:

This is what I get in the logs:

2023-09-27T19:17:23.955421Z DEBUG activitypub_federation::activity_queue: Activity https://lemmy.fbmac.net/activities/undo/506ed9a4-bfee-472f-8249-f802639eec8d was rejected by https://lemmy.world/inbox, aborting: Request error: error sending request for url (https://lemmy.fbmac.net/u/fbmac): error trying to connect: tcp connect error: Address not available (os error 99)

I think it kind of confirms, lemmy.world is unable to contact mine back.

What servers are really IPV6, so I can actually federate with something?

I'm curious about something so I'm going to throw this thought experiment out here. For some background I run a pure IPv6 network and dove into v6 ignoring any v4 baggage so this is more of a devils advocate question than anything I genuinely believe.

Onto the question, why should I run a /64 subnet and waste all those addresses as opposed to running a /96 or even a /112?

1. It breaks SLAAC and Android

let's assume I don't care for whatever reason and I'm content with DHCP, maybe android actually supports DHCP in this alternate universe

2. It breaks RFC3306 aka Unicast-prefix-based multicast groups

No applications I care about are impacted by this breakage

3. It violates the purity of the spec

I don't care

What advantages does running a /64 provide over smaller subnets? Especially subnets like a /96 where address count still far exceeds usage so filling subnets remains impossible.

Has anyone messed with using the very large jumbo frames for IPv6 for anything like video transfer, or large file transfers?

I'm curious if anyone has done it for firewall overhead reduction too

A few weeks ago, Lemmy started using Service Workers, which Chrome associates with an origin (e.g. https://lemmy.world/) instead of a specific tabId.

IPvFoo had been ignoring these requests, which resulted in a lot of missing data. I just pushed v2.7 to the Chrome Web Store, so Lemmy should show a 4/6 again when it's published in a day or two.

The old version still sort of works if you Ctrl-Reload the page.

Their new modem/router doesn't support opening ports in the ipv6 firewall, so if you want to open ports, they recommend disabling ipv6 entirely. For ipv4, they no longer support forwarding ports from only specific source addresses either, which is way less secure. You can only forward ports from all source addresses. You also have to use their crappy app to add port forward rules, it's no longer available in the web ui. You can completely disable the ipv6 firewall in the web ui, but that wouldn't be safe.

Old motorola modem/routers could do all of the above.

It says it can do bridge mode at least, but it seems silly to need 2 devices just to open ipv6 ports.

How are routers being made now in 2023 that don't have proper ipv6 support? It seems crazy to me.