Home staking behind CGNAT, LATAM, Asia-Pacific, and everywhere
EthCC[9] · 1 Apr 2026 · 9:22
Yorick Downe explains why carrier-grade NAT limits home-staking connectivity at the execution and consensus layers. The presentation reviews client support and demonstrates using IPv4 and IPv6 together to improve peering and resilience.
Speakers
Topics
From EthCC[9], hosted by Ethereum France.
Transcript
All right, wonderful. Uh, we're coming up on lunch. So, I have this ambition that I'm going to fly through this and we'll have time for questions or lunch. So, home staking behind CGNAT, I'm going to first explain what the issue is and then how to solve it. Um, CGNAT is carrier grade NAT. So, the challenge here is that in many parts of the world we have truly run out of IPv4 addresses. Um, your machines, you know, have to talk to the internet. They do this with two different address schemes. One is called version four, one is called version six.
Um, so what that means is that if you're now behind carrier grade NAT, network address translation, you cannot forward ports. If you've done home staking, you've probably heard you should forward your port so you get good peers on the consensus layer so that um, your inclusion distance is good so you get good rewards. Once you're behind CGNAT, you can no longer do that. It's it's just impossible because it happens at the carrier um, router, not at your home router.
So, the good news is um, also don't use um, AI to make your your slides. There's a little knock that's looking unhappy because it's being excluded from the peering. So, the solution is you run dual stack. Um, the the TLDR is this now works as of actually March 2026. This is fairly new that we have enough clients where this works. So, the dual stack in your network is probably already provided by the ISP and by your router.
Um, there's not much you need to do on the operating system itself for your node. There was probably an option during installation to say I want IPv6 addresses. If you didn't choose that, ask Google or chat GPT how to enable that so your dual stack. Um, uh, this really works now on three consensus layer clients and that way you have the incoming peers on IPv6 and outgoing on both IPv4 and IPv6. And you have enough peers to, you know, get your your attestation included in time and get good rewards.
On the execution layer, this is a lot less urgent. You only need a handful, like literally five or less peers to just get the block. Um, so while there's only one execution layer client that can currently do this, um, that's I I'll I'll go out on a limb and say that's fine. The consensus layer is what you're worried about. Um, we have ipv6.eth.info maintained by Sonic which tries to have like a status of which clients support this well. Currently on the consensus layer, I would recommend Lodestar, Lighthouse, and Grandine without any reservations there.
They all work great. They all can detect the external IPv6 automatically even when it changes. That's very important for home stakers. And Besu. Um, I think Reth and Erigon are also working on it, but it's not ready. For implementation, if you're running So, I'm going to be EthDocker-centric because I maintain the thing, but this works of course in systemd if you're like using a systemd guide or something like that. Um, in EthDocker it's really damn simple. You go into the env file and you say IPv6 equals true and you restart your clients and that's it. Everything else is abstracted from you. You don't need to think further.
Um, that includes SSV and CLs. Um, it's not supported in Rocket Pool. I asked the Rocket Pool devs about this and they said it's not complicated. They could support it. They just haven't. Um, for systemd users, uh, like if you have a systemd you could look at the EthDocker code and just rip out the parameters you need and do it that way. You could also use a client that has dual stack by default, ipv6.eth.info, so you don't have to configure anything.
Um, it's not too scary. Uh, security. That's an important one. So, UFW, the the firewall in Linux, supports IPv6. There's a way to place UFW in front of Docker if you're using EthDocker and you're in the cloud so that it controls um, this. That's not important for peer-to-peer. Obviously, you don't want to firewall the peer-to-peer ports, but it's important if you're like running Grafana or something and then you know, you're like, now now Grafana is available on IPv6, how do I how do I firewall this?
Um, we've worked through this with some members of the EthStaker crew and some, you know, uh, um, fans in EthStaker Discord and we now have a working implementation of this. So, that's I think as of February. Um, and yeah, your router of course has it, allow it in. That's it. From there, we're black, okay? Um, you can either get lunch or ask questions. >> [applause] >> Yeah, the TLDR really is it works now.
Go use it. >> [snorts] >> Hello and thank you for the talk. Um, I have a very, let's say low grade internet provider that only allows you to get yourself uh, from being behind of CGNAT to not be behind, but it never gives you a truly static IP. So, every time they do any sort of a maintenance, which might happen like each 24 hours, Mhm. um, even though I have an external IP4 address,
this address is changed frequently. So, from your experience, what would you advise to go back behind CGNAT and use this setup or stay at the setup that I have and accept the fact that IP4 address is getting changed like almost every 24 hours. Right. Um, I In in your case, since you have a public V4, I would keep it. And then [snorts] I would still run dual stack. Your ISP probably also gives you V6.
So, you can still run this dual stack thing whether you're behind CGNAT or no. Um, and all of the clients on V4 at least do the auto ENR, so the the, you know, auto detection of the public IP. So, whenever it changes, they should auto detect that and have that in discovery. Um, and then you'll also have the V6 in addition. That's how I would run that. For lunch?
You can go ahead and do that. Too hasty with the lunch, okay. Oh. Wait. >> [clears throat] >> So, one is that, uh, do you have data on how many nodes are behind NAT and kind of nodes and how many of them there are actually facing connectivity issues? I don't. And connected to that is like, what's the default usually? I mean, is the Ethereum nodes, what do they do when they are behind NAT? Do they try to do any NAT traversal? Sorry, when you say the defaults? I mean, if they're not using IPv6, so what is the other alternative? There The alternative is that you only have outgoing connections if you're behind CGNAT in particular, carrier grade NAT.
So, this talk kind of came out of, um, a talk I held at a Lido event a while ago. Um, I briefly mentioned CGNAT in in the context of running home nodes like a pro and a woman came up to me after and said, "Thank you. This is the first time anybody talked about this. This is the main reason we can't run nodes in my country here in, uh, South America." So, that was good because it, you know, gave me So, to your question of how prevalent is this? Probably not very in North America, somewhat in Europe. You'll see a lot of it in South America and Latin America, in Asia Pacific, and Africa. Um, but the a lot of people
still have access to a public IPv4 at their at their own router. So, you know, this little anecdote there, this was good for me to know I'm not just Don Quixote tilting at the IPv6 windmill. There is an actual use case for some people in the world. Thanks everyone.