Jen also had a presentation recently (2024-11) at RIPE87, "Mission Possible: How Google Plans to Turn Off IPv4!", where they've managed to reclaim 300K IPv4 addresses:
NAT64 covers most of the cases. However, in my homelab experiements I very quickly found out that IPv4 literal addresses are a bit problematic for me.
There are ways to fix that with 464XLAT/CLAT, but I never got around to deploying it.
These days I'm just running dual-stack, with no NAT64. I hate NAT with a burning passion, so adding another layer of stateful NAT is a bit of a net negative in my eyes.
Someday I'll go full IPv6 on my home network with 464XLAT. And then I'll realize that some stupid IoT device or something is not CLAT aware. Obviously there are solutions around that too, but they require an intermediate device.
If you have NAT64, DNS64 and use “IPv6-mostly” option 108 on DHCP, then CLAT will be activated on supporting devices automatically - and then you can turn the dhcpv4 off when you see no leases on it :-)
True :) the nice thing with 108 is that it is supposed to be “seamless” - that is, you will see (by the absence of leases) that “it’s finally time” to remove it. And the legacy old devices will still continue to work till then.
I resigned myself to the fact that IoT crappy devices will always exist and I isolated these to their own VLAN with IPv4-only (maybe I'll go dual-stack at some point).
Yes, VLANs add complexity -- even the obligatory IoT VLAN -- but I generally want to keep these IoT devices isolated anyway.
I used Jool! It worked great, but with some caveats.
My ISP does DS-lite which is some abomination where the shared (split by port) IPv4 address is calculated based on the IPv6 address? Using a fixed mapping table? Which is both very popular here and has zero linux support.
They had another option to do PPPoE IPv4 + SLAAC IPv6, but for this option they didn't support DHCP prefix delegation. So I had to use this, and to work around that I needed to make my IPv6 network bridged.
The problem is Jool hooks into the linux routing table, and in the bridged network none of the outbound packets reach that table. So I had to 1. rewrite their RAs with my own DNS64 server and 2. mangle NAT64 packets to look as if they're sent to the router directly so they hit the routing table (and get processed by Jool): https://github.com/andrewbaxter/portalino/blob/main/source/o...
Then I hit random MTU issues. MTU should be auto configured (and fixed when there's issues) but I saw problems with Chrome/Firefox refusing to load pages until I tried again at least 30s later until I forced the MTU lower.
It should be noted in-network DNS64 is a fallback for situations where end devices don't have native support for NAT64 (either with a CLAT or with local DNS64). (Network side DNS64 breaks DNSsec)
RedHat is working to get CLAT on regular Linux hosts, where it has been direly missing.
I guess this is because sometimes hosts use bare IPv4 address and don't go through DNS and thus DNS64 doesn't work for them? And if the host supports translating the addresses itself (CLAT) why use DNS64 at all?
But this is the first time I've heard of that. Do any devices support it at all? I'm still struggling with IPv6 issues on my iphone.
Desktop Linux is to my knowledge the only "major" OS without a CLAT; Android and iOS/MacOS have had a CLAT for ages and I believe Windows got one recently*.
* not sure about that
> I guess this is because sometimes hosts use bare IPv4 address
This, and also legacy applications just not using IPv6 sockets.
I have to admit, at first read I thought the headline was referring to the e-cig Juul and I was scratching my head wondering how one could build an ipv6 mesh network out of vapes.
It's not immediately clear from the page but this is a NAT style hack for people who don't have normal IPv6 connectivity, and NAT'ed connectivity is inferior to native.
You either mistyped IPv4 as IPv6 or misunderstood the setup. There is native ("normal") IPv6, but no IPv4 except on the NAT64 host. Since IPv4 is almost always NATed for end hosts, it's not inferior in any way.
I would love to do something like this except Verizon only provides IPv4 in my area. Some of the. Workarounds, like IPv6 tunnels, seem to have big drawbacks like being blocked by major providers.
I wish it were possible to force major operating systems to prefer IPv4 over IPv6, which might be a viable workaround to a less reliable IPv6 workaround, but such a configuration appears to be unfeasible for mobile phones, Windows, and perhaps MacOS too.
I have my main VLAN, a guest VLAN, and one for any 'smart'/IoT devices that need to connect to cloud services. Each is firewalled from each other and each has its own separate WiFi SSID.
Not just because the IoT devices are prone to attack because they may not get many updates, but also because they often need 2.4 GHz or may only support WPA 2. So my main network can be WPA3 only and 5 GHz only but the other networks are more lenient.
I have multiple VLANs on my home LAN. It's just so much easier to provide no-Internet or isolated-from-all-other-non-guest-hosts service if you set that up via VLANs. I might be mistaken, but it's my pretty strong understanding that with everything on the same VLAN, you have to deal with hosts using MAC and/or IP address spoofing to evade your router firewall rules. [0]
[0] Because what else would you use to decide how to block or permit traffic if you can't distinguish by the interface that the traffic came in on?
It's starting to get a bit more common but in a roundabout way. Telus managed Wifi routers can provides isolated guest networks, which AFAIK uses VLAN's and firewall rules internally. It's not visible to the end user though.
But the topology given in the article shows three separate, non-overlapping /64s, one for each host/router. (Although one would assume that the router at least must have an interface in each subnet, even if that's not what the diagram shows).
One might hope these would be on separate VLANs, as overlaying multiple subnets on one VLAN would be a bit iffy. I've not spotted anything in the article other than the diagram to detail interface configs.
Why do I need to even think about entering a contractual relationship with "13 TCF vendor(s) and 64 ad partners" before reading a blog post? The subject sounded interesting but the lack of respect for me is enormous.
The UK IPv6 Council has a bunch of videos on running IPv6-mostly/only networks:
* https://www.youtube.com/@ukipv6council468/videos
This includes at academic institutions where it's basically all BYOD so they have to deal with a more 'random' assortment of systems:
* https://www.youtube.com/watch?v=2B-liebzcOM
And enterprise networks, like Jen Linkova at Google:
* https://www.youtube.com/watch?v=hb98hAb5_W8
Jen also had a presentation recently (2024-11) at RIPE87, "Mission Possible: How Google Plans to Turn Off IPv4!", where they've managed to reclaim 300K IPv4 addresses:
* https://www.youtube.com/watch?v=UTRsi6mbAWM
She's currently co-chair of the IETF IPv6 Maintenance (6man) working group.
NAT64 covers most of the cases. However, in my homelab experiements I very quickly found out that IPv4 literal addresses are a bit problematic for me.
There are ways to fix that with 464XLAT/CLAT, but I never got around to deploying it.
These days I'm just running dual-stack, with no NAT64. I hate NAT with a burning passion, so adding another layer of stateful NAT is a bit of a net negative in my eyes.
Someday I'll go full IPv6 on my home network with 464XLAT. And then I'll realize that some stupid IoT device or something is not CLAT aware. Obviously there are solutions around that too, but they require an intermediate device.
If you have NAT64, DNS64 and use “IPv6-mostly” option 108 on DHCP, then CLAT will be activated on supporting devices automatically - and then you can turn the dhcpv4 off when you see no leases on it :-)
By now there is a fair amount of material, eg:
https://indico.cern.ch/event/1274792/contributions/5444353/a...
Nit: you still need DHCPv4 to send 108 ;)
But also CLAT should turn on if a PREF64 is known and no IPv4 is available, regardless of 108.
True :) the nice thing with 108 is that it is supposed to be “seamless” - that is, you will see (by the absence of leases) that “it’s finally time” to remove it. And the legacy old devices will still continue to work till then.
I resigned myself to the fact that IoT crappy devices will always exist and I isolated these to their own VLAN with IPv4-only (maybe I'll go dual-stack at some point).
Yes, VLANs add complexity -- even the obligatory IoT VLAN -- but I generally want to keep these IoT devices isolated anyway.
I used Jool! It worked great, but with some caveats.
My ISP does DS-lite which is some abomination where the shared (split by port) IPv4 address is calculated based on the IPv6 address? Using a fixed mapping table? Which is both very popular here and has zero linux support.
They had another option to do PPPoE IPv4 + SLAAC IPv6, but for this option they didn't support DHCP prefix delegation. So I had to use this, and to work around that I needed to make my IPv6 network bridged.
The problem is Jool hooks into the linux routing table, and in the bridged network none of the outbound packets reach that table. So I had to 1. rewrite their RAs with my own DNS64 server and 2. mangle NAT64 packets to look as if they're sent to the router directly so they hit the routing table (and get processed by Jool): https://github.com/andrewbaxter/portalino/blob/main/source/o...
Then I hit random MTU issues. MTU should be auto configured (and fixed when there's issues) but I saw problems with Chrome/Firefox refusing to load pages until I tried again at least 30s later until I forced the MTU lower.
So close, but still so far.
I've bumped into ds-lite alot for my Japanese friends living in Tokyo. I really don't like it to say the least.
It should be noted in-network DNS64 is a fallback for situations where end devices don't have native support for NAT64 (either with a CLAT or with local DNS64). (Network side DNS64 breaks DNSsec)
RedHat is working to get CLAT on regular Linux hosts, where it has been direly missing.
I guess this is because sometimes hosts use bare IPv4 address and don't go through DNS and thus DNS64 doesn't work for them? And if the host supports translating the addresses itself (CLAT) why use DNS64 at all?
But this is the first time I've heard of that. Do any devices support it at all? I'm still struggling with IPv6 issues on my iphone.
Desktop Linux is to my knowledge the only "major" OS without a CLAT; Android and iOS/MacOS have had a CLAT for ages and I believe Windows got one recently*.
* not sure about that
> I guess this is because sometimes hosts use bare IPv4 address
This, and also legacy applications just not using IPv6 sockets.
I have to admit, at first read I thought the headline was referring to the e-cig Juul and I was scratching my head wondering how one could build an ipv6 mesh network out of vapes.
It's not immediately clear from the page but this is a NAT style hack for people who don't have normal IPv6 connectivity, and NAT'ed connectivity is inferior to native.
You either mistyped IPv4 as IPv6 or misunderstood the setup. There is native ("normal") IPv6, but no IPv4 except on the NAT64 host. Since IPv4 is almost always NATed for end hosts, it's not inferior in any way.
So it seems, I stand corrected.
I would love to do something like this except Verizon only provides IPv4 in my area. Some of the. Workarounds, like IPv6 tunnels, seem to have big drawbacks like being blocked by major providers.
I wish it were possible to force major operating systems to prefer IPv4 over IPv6, which might be a viable workaround to a less reliable IPv6 workaround, but such a configuration appears to be unfeasible for mobile phones, Windows, and perhaps MacOS too.
Would love to enable NAT64 on my OpenWRT router, sadly setting up Jool on OpenWRT feels to hacky to me. Based on option 2 described here: https://openwrt.org/docs/guide-user/network/ipv6/nat64
Not sure I entirely agree with :
"Here is the classical topology of home network." ... "And all the LAN hosts have one /64 IPv6 prefix."
Are people really deploying IPv6 like this? Rather than a /64 to a vlan?
(Personally, in the home, I'm just using DHCPv6-PD to delegate a different /64 to each VLAN).
Who has multiple VLANs in a home network??
I have my main VLAN, a guest VLAN, and one for any 'smart'/IoT devices that need to connect to cloud services. Each is firewalled from each other and each has its own separate WiFi SSID.
Not just because the IoT devices are prone to attack because they may not get many updates, but also because they often need 2.4 GHz or may only support WPA 2. So my main network can be WPA3 only and 5 GHz only but the other networks are more lenient.
My router configures a VLAN for guest network access, and that's a normal consumer Fritz!Box. I think other brands do the same.
People may not know they're running a VLAN, but VLANs aren't uncommon either.
I have multiple VLANs on my home LAN. It's just so much easier to provide no-Internet or isolated-from-all-other-non-guest-hosts service if you set that up via VLANs. I might be mistaken, but it's my pretty strong understanding that with everything on the same VLAN, you have to deal with hosts using MAC and/or IP address spoofing to evade your router firewall rules. [0]
[0] Because what else would you use to decide how to block or permit traffic if you can't distinguish by the interface that the traffic came in on?
It's starting to get a bit more common but in a roundabout way. Telus managed Wifi routers can provides isolated guest networks, which AFAIK uses VLAN's and firewall rules internally. It's not visible to the end user though.
https://www.telus.com/en/support/article/create-a-guest-netw...
Definitely the realm of homelabbers, but I do. Mainly to segregate IoT devices, users, lab servers.
That is only because I want to though, I agree that the average home network will not have VLANs.
I don't think an average home user even knows what a VLAN is.
This, on the other hand, is Hacker News.
HN has a surprisingly low level of network knowledge compared to sites a generation ago (slashdot etc)
The question was about users in general, not HN users in particular.
Also, just because you know how to do it, doesn't mean you want to tinker with a complex network topology on your home network.
Or maybe a "classical" (I assume author meant "typical"?) home network does not have multiple VLANs.
Agreed.
But the topology given in the article shows three separate, non-overlapping /64s, one for each host/router. (Although one would assume that the router at least must have an interface in each subnet, even if that's not what the diagram shows).
One might hope these would be on separate VLANs, as overlaying multiple subnets on one VLAN would be a bit iffy. I've not spotted anything in the article other than the diagram to detail interface configs.
Doesn't openbsd do this without out of tree kernel modules? I'm kind of allergic to dkms and friends.
OpenBSD do stateless NAT64. You can do the same on linux using Tundra in userspace.
I read Jool and expected something in Kerbal Space Program. For example, here's some network setup around Jool: https://youtube.com/watch?v=n2eBwgW6sig
See also perhaps "IPv6-mostly on OpenWRT" from RIPE 87:
* https://www.youtube.com/watch?v=GZ6pxh6ukCg
* https://ripe87.ripe.net/archives/video/1136/
* https://ripe87.ripe.net/wp-content/uploads/presentations/8-I...
Ansible roles:
* https://github.com/oskar456/ansible-openwrt-ipv6-mostly
Why do I need to even think about entering a contractual relationship with "13 TCF vendor(s) and 64 ad partners" before reading a blog post? The subject sounded interesting but the lack of respect for me is enormous.
Just read the Jool documentation which is vastly superior: https://nicmx.github.io/Jool/en/documentation.html#introduct....