//TODO: Monostack

Upstream Linux SIIT

Antonio and Alberto (and to a lesser extent Daniel) are currently working on refactoring Jool's stateless translation (SIIT) code into a minimum viable SIIT virtual network device. Unlike previous attempts we're aiming for upstream inclusion.

Code: joolif-net-next on Codeberg, because we should #GiveUpGithub.

Details on our designs page, Minimum viable SIIT device.

Naming the upstream driver

(hardest problem in computer-science)

We have a winner: CONFIG_IPV6_IPXLAT.

Previous candidates:

- CONFIG_IPV6_SIIT_DEV - maximally confusable with CONFIG_IPV6_SIT, maybe
  CONFIG_IPV6_SI2T_DEV?

- CONFIG_IPV6_JOOL_SIIT_DEV

- CONFIG_IPV6_SIIT_JOOLIF

- CONFIG_MONOSTACK_SIIT_DEV - branding may be offputting to upstream

- CONFIG_RFC6145_DEV - worst case

We wish SIIT didn't have such a terrible acronym. Probably part of the reason it hasn't seen major adoption so far ;-)

Look into performance and correctness testing tools

lencsegabor/siitperf (GitHub) seems the most promising. It's research software (ugh) but extensively documented in at least five different papers of theirs. Also purpose built which is nice. Could be a problem if it's too pedantic about NAT64 RFC compliance tho.

Integrate NAT64/CLAT into Linux distros

Daniel is planning to eventually getting around to thinking about maybe starting to design CLAT integration for Debian. NAT64 is easier since we can make some demands of the OS environment. Overall idea is $ apt install monostack-nat64 would arrange things to bring up a SIIT translation device at boot and appropriately configure nftables using drop-ins.

OpenWrt integration is also on the roadmap. Interestingly they have an existing out-of-tree kernel module (kmod-nat46, nat46 git) to provide CLAT functionality, but not NAT64. It's already integrated into the appropriate hooks for CLAT (and even MAP-T) see network/ipv6/{464xlat,map}. Once our upstream driver is available it should therefore be straightforward to switch.

For NAT64 we still have to investigate how best to integrate. Perpaps as a netifd protocol on the virtual device? We may also have to integrate with firewall4 for the nftables bits.

We're looking for interested people in the OpenWrt community to help with design and communication work here. Tell us if you're interested or know someone that might be.

Design socket level SIIT translation

Idea: ip siit prefix add 64:ff9b:1::/96 dev eth0 and suddenly IPv4 literals just work. The kernel (v4) socket layer would call the SIIT translation functions internally.

Note: Prefix needs to be per-interface for multihoming.

Upstream Linux CONFIG_IPV4=n

Currently IPv4 support is implied in the kernel and IPv6 support is optional. In time we want to turn this situation around, making the legacy protocol optional. This is tricky refactoring work deep in net/ that's going to take years, still it's time to start chipping away at this.

Finish Website

Gather community feedback and TODO items

Figure out Mailinglist hosting

Decided on mlmmj list-manager hooked up to exim with rspamd config based on ISPmail. Archiving via public-inbox.

Spam handling: configure dovecot+sieve+cronjob so multiple project members reading but not trashing/moving list mail in their IMAP account will make it go out to list or after a timeout.

Hosting: Want a clean /48 for email sending reputation not many hosts offer it. Can use Daniel's AS212704, but is SPoF. https://netshelter.org membership/sponsoring is WIP. Lemmi offered tunnel via https://sub.f3netze.de. In any case can use multiple ranges for resilient sending using exim interface: ${rand...} trick (*overflow). Can even make IPs used depend on recipient domain or any such crazy thing.

Draw some nice ASCII diagrams of monostack deployments

Anyone feeling artistic?

Implement news with RSS/Atom feed

Postponed, fake-it-til-you-make-it style. Just write it by hand until it becomes annoying :D

Idea: generate per-page RSS feeds from git history.

Gather info on BSD ecosystem

The Windows Elefant in the Room

Microsoft has promised they're going to have a CLAT soon^TM, recently (Nov 18, 2025) Windows CLAT entered private preview. See also Tommy Jensen's talk: IPv6 in Windows.

If that doesn't pan out Jason wrote a very nice high performance and FLOSS Layer 3 NT kernel driver for Wireguard. We could use it as a template for a FLOSS CLAT, just need to figure out how to do the network configuration :-) WireGuardNT.

We're looking for someone interested in working in this area.

What about Linux Desktop/Mobile?

Depending on the system use-case different components are relevant. We have people focusing on the server/embedded use-case and consequently stuff like ifupdown{,-ng}, dhcpcd and systemd-networkd. We're still looking for people knowledgable on the Linux Desktop/Mobile side of things. That essentially means NetworkManager, but maybe there's other tools we don't know about.

Tell us if you are or know someone interested in devel in this space >3

That being said NetworkManager is making moves on CLAT support (#1435) and PR !2107 but we're not in contact with the people involved in that work ... yet.

Build a Monostack focused router gizmo

(Just a hobby, won't be big and professional like *Sense)

Idea: see README.html#gizmo

Intent: minimally configurable. This is emblematic of IPv6, you don't need to configure as much of anything anymore to get a working system.

For example port forwarding is obsoleted by end-to-end approaches such as firewall policy based on (DHCPv6 delegated) prefix or ip-token(8) based marking of server hosts in mixed LANs.

Note: Can use our ,nftt script for promotional material :)

Provide easy legacy- vs real-internet traffic visibility

i.e. a nice dashboard to convince ourselfes and our bosses this IPv4 thing has, in fact, become historic.

Per-host monostack control

Toggles: DNS64 y/n, v6-only-preferred y/n.

DNS64 control could get tricky depending on where hosts get their DNS info from. Could be: RA RDNSS list, DHCPv4 DNS or DHCPv6 DNS. DHCP options allow easy per-host control, for RA only with a custom daemon that unicasts adverts to individual hosts. Any takers for that hackery?

Might also need a way to detect what info a client is using. We should use unique DNS service addresses across all information sources. That way we can gather per-host statistics on who uses what.

Decide on Debian vs. OpenWrt as a base

Maybe both? Us FLOSS crazies do love options.

Test and document monostack support

It's important to know which OS implementations support what. There are lots of TODOs missing under here. Get patching.

Do platforms respect the IPv6-only-capable requirement of RFC 8925?

RFC 8925 "IPv6-only-capable host".

Fixed systemd-networkd tracking issue: https://github.com/systemd/systemd/issues/30891.

Do CLATs react to translation prefix changes?

Remember to test with DNS64 and PREF64. Came from a discussion wit Kasper, might be interesting for using off-site hosted NAT64 services.

Android

Use WireGuard for Android App, setup two tunnels: one with AllowedIPs=::/0, one with AllowedIPs=::/1, 8000::/1. The former blocks v4 (underlay) access the latter doesn't..

Fix known problematic code

Linux

This is a problem for our monostack because it neutralizes a hugely important feature of IPv6 over legacy IP — for environements that care about Linux anyway. With this you can plug a router into another LAN and expect it to work out of the box.

Jiri from SUSE tried to have this fixed in 2014 but Hannes objected over vague VPN route bypass concerns: "[PATCH] ipv6: set acceptrartinfomax_plen to 128 by default" https://patchwork.ozlabs.org/project/netdev/patch/20140319172210.GA29745@midget.suse.cz/

We know this is a general problem now cf. "Bypassing Tunnels" (rogue LAN with DHCPv4 subnet colliding with VPN net) and "Tunnel Vision" (DHCPv4 route option, sound familiar?). So that concern is moot. Use VRFs for VPNs people!

Meanwhile Joel from Google implemented restricting the size of the prefix https://lore.kernel.org/netdev/20170322091904.73420-1-jscherpelz@google.com/ should probably also have a sane default if we're going to change anything here.

We thought this could be worked around by using "off-link" L=0 PIOs in router-lifetime=0 RAdverts instead of RIOs but apparently that's just a dhcpcd bug we were taking as gospel. RFC 4861 toghether with RFC 5942 are pretty clear on the fact that off-link destination should be sent to a default router.

RFC 4861:

If the destination is on-link, the next-hop address is the same as the packet's destination address. Otherwise, the sender selects a router from the Default Router List (following the rules described in Section 6.3.6).

RFC 5942:

IPv6 packets sent using the Conceptual Sending Algorithm as described in [RFC4861] only trigger address resolution for IPv6 addresses that the sender considers to be on-link. Packets to any other address are sent to a default router. If there is no default router, then the node should send an ICMPv6 Destination Unreachable indication [...]

Syncthing

Uses address literals for sync connections. Should work with CLAT but performance is an issue with userspace CLAT implementations.

https://github.com/syncthing/syncthing/issues/9917

A /24 saved is a /64 gained.

Itching to get started? We're waiting: ipv6@lists.monostack.org

Last changed: 2025-12-12