Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NAT Is the Enemy of Low Power Devices

blog.golioth.io

Post reply on HN
Print view View original

41–50 of 180 posts

Re: NAT Is the Enemy of Low Power Devices

#41

Post by jeroenhd »

LegionMammal978 wrote: post #9
api wrote: post #5

Earlier quoted context omitted.

Why?

Eliminating NAT makes virtual networking much hairier. E.g., my desktop is currently connected to a big enterprise network that keeps track of all devices and will only allocate one IP address per MAC address. That leaves no IPs for any VMs on my desktop to use, so they must go through NAT if they want to communicate with the outside world.

Based on your description, you're using NAT as a means to bypass network restrictions. It's a great hack that will do the trick wonderfully, but if that's the officially proposed solution then the network is not set up for what it's actually used for.

Contrary to popular belief, IPv6 does have NAT, it's just stupid and unnecessary in most use cases. There are even different kinds of NAT; there's the "swap the public prefix with a private one" NAT (useful for shit ISPs that rotate your IPv6 prefix to make you pay extra for a static one, so your addresses don't keep changing), or the IPv4-like "masquerade all traffic when forwarding" one that'll work in your weird enterprise network.

With the latter option, you can set up an IPv6 with DHCPv6 on the upstream and whatever combination of SLAAC or DHCP you want on the VM side, and set up NAT using guides like this (possibly outdated iptables-based) one: https://forums.raspberrypi.com/viewtopic.php?t=298878

Re: NAT Is the Enemy of Low Power Devices

#42

Post by jeroenhd »

pjc50 wrote: post #29
LegionMammal978 wrote: post #9

Earlier quoted context omitted.

Eliminating NAT makes virtual networking much hairier. E.g., my desktop is currently connected to a big enterprise network that keeps track of all devices and will only allocate one IP address per MAC address. That leaves no IPs for any VMs on my desktop to use, so they must go through NAT if they want to communicate with the outside world.

Shouldn't the VMs have their own MACs?

If they're not routed directly through the network card but use a virtual switch instead, the network upstream only sees the server MAC. If they're directly hooked into the network card they can have their own MACs, but that approach can make it hard to communicate between host and VM.

Re: NAT Is the Enemy of Low Power Devices

#43

Post by namibj »

LegionMammal978 wrote: post #7
justahuman74 wrote: post #2

Interestingly, IPv6 is not listed as the solution

An IPv6 router with a stateful firewall blocking incoming connections could have just the same issues with timeouts, I'd imagine. Switching to IPv6 doesn't just mean that anyone can make a P2P connection to anyone else (even STUN needs a third-party server to coordinate the two peers). (D)TLS session resumption (I'm not sure if their "Connection IDs" are that or something similar) seems like the most foolproof soluti…

But it'd be trivial to tell it to free the device from it, unlike with NAT, where you pretty much have to expire sessions to not run out of memory.

Re: NAT Is the Enemy of Low Power Devices

#44

Post by jeroenhd »

elcritch wrote: post #28
Joel_Mckay wrote: post #8

Earlier quoted context omitted.

In general, the IPv6 stack is not supported on many smaller mcu. It is not that options like FreeRTOS can't support the stack, but rather the resource constraints pose a challenge. That being said, most modern SoCs are competitively priced... and will boot Linux just fine for under $5/part. =3

Some of the new IoT protocols build on ipv6 natively. The resource overhead is minimal for modern mcus. Dropping dhcp and arp can save a lot of resources too. Also I have mcus with more ram than my first pc.

Disabling IPv6 in ESP-IDF can save about 40KiB of flash and 2KiB of RAM. Not enough that I'd do it by default, but I've hit the limit of some of my hobbyist ESP32s to the point where I've disabled modules to cram my code in there.

Disabling IPv4 saves 25KiB of flash and less than a KiB of RAM. If you're down to the last kilobytes, disabling IPv6 makes more sense than disabling IPv4. Both options are choices of last resort, though.

Re: NAT Is the Enemy of Low Power Devices

#45

Post by vollbrecht »

dent9876543 wrote: post #22

That NAT is a problem presumes that we actually want our IoT devices reaching out to the out-of-intranet zone. NAT gets the blame, and the intranet as a concept is generally a big corp term. But I prefer my IoT devices not to need to reach out of my network. For me, NAT is an unwitting ally in the fight against such nonsense.

The mere existence of Tailscale should give a hint that NAT is only a speedbump and not any protection whatsoever. It protects you against nothing. Every method that Tailscale uses to traverse NAT can be in isolation used by any other piece of software. For more info about that you can read the following article.

https://tailscale.com/blog/how-nat-traversal-works

Re: NAT Is the Enemy of Low Power Devices

#46

Post by apple1417 »

I have worked on a device with this exact same "send a tiny sensor reading every 30 minutes" use case, and this has not been my experience at all. We can run an STM32 and a few sensors at single digit microamps, add an LCD display and a few other niceties and it's one or two dozen. Simply turning on a modem takes hundreds of microamps, if not milliamps. In my experience it's always been better for power consumption to completely shut down the modem and start from scratch each time [1] - which means you're paying to start a new session every time anyway. Now I'll agree it's still inefficient to start up a full TLS session, a protocol like in the post will have it's uses, but I wouldn't blame it on NAT.

[1] Doing this of course kills any chance at server-to-device comms, you can only ever apply changes when the device next checks in. This does cause us complaints from time to time, especially for those with longer intervals.

Re: NAT Is the Enemy of Low Power Devices

#47

Post by jeroenhd »

gamedever wrote: post #27
nrabulinski wrote: post #14

Earlier quoted context omitted.

Unless IPv6 were to be actually adopted as it was introduced

I don't know networking all that well. In my mind, I have 50 devices connected to my router behind NAT. My Mac, My Apple TV, my iPhone, My PC, My Linux Box, My partner's versions of all of those. My video games. Etc From outside there's 1 IP address. With IPv6, every device would get it's own address outside. Why do I want that? That sounds less private to me. Am I mis-understanding something? Lots of traffic on one…

With IPv6, every device has multiple IP addresses. One or more addresses that are rotated* to prevent you from being tracked easily, and one that's derived from your device's MAC address so you can make your devices easily accessible from WAN by opening ports in your firewall if you want to.

You could disable the rotating addresses, or disable MAC-based ones by using DHCP, but there's usually no point.

As for why you would want something like that: a whole bunch of software and hardware breaks because of NAT. Consumer NAT has some monkey patching inside of it rewriting some protocols to make them work again (which also allowed random websites to open arbitrary ports to arbitrary addresses in some Linux routers a while back, because NAT overrules firewall settings to work) but there are still limitations.

For instance, if you're having issues with your Nintendo Switch, Nintendo will tell you to forward every single port to your Switch (https://en-americas-support.nintendo.com/app/answers/detail/..., hope that IP address doesn't get reassigned to an unpatched device later). Multiple Xbox consoles behind the same NAT requires tricking them into super-restricted-NAT mode to work, or enabling UPnP which allows devices to open ports in your firewall without any authentication.

NAT just kind of sucks. IPv6 wasn't ready for deployment when NAT gained popularity, but all of the reasonable problems have been solved over a decade ago.

*=default rotation happens daily, but your OS may allow you to pick a shorter duration. I've found out the hard way that setting this to five minutes will fill up Linux' route table real fast after a few days.

Re: NAT Is the Enemy of Low Power Devices

#48

Post by dent9876543 »

rcxdude wrote: post #38
dent9876543 wrote: post #22

That NAT is a problem presumes that we actually want our IoT devices reaching out to the out-of-intranet zone. NAT gets the blame, and the intranet as a concept is generally a big corp term. But I prefer my IoT devices not to need to reach out of my network. For me, NAT is an unwitting ally in the fight against such nonsense.

If you don't want that, then complain about a lacking a configuration as such and configure your firewall so that that they can't. But don't cheer on something that's breaking functionality that others might want (especially if it doesn't actually achieve your own goals reliably).

Oh, I do that too.

But to your point about not cheering on NAT, well I will because I see NAT as useful tool.

It is not an opinion well aligned with the preferences of the IETF. But the purist model of transparent end-to-end networking has never sat well with me. It’s just not a thing we want.

Re: NAT Is the Enemy of Low Power Devices

#49

Post by p_l »

arcmechanica wrote: post #10

NAT was an good solution that the IETF came up with, we wouldn't be able to have the internet at our scale without it

NAT was introduced by private company called Network Translation Inc. and successfully broke efforts to migrate off IPv4 (which was supposed to be EOLd by 1990) and permanently broke the "network of hosts" into asymmetric one of servers and clients.

Note that we had a solution for address exhaustion by 1991, but it was just "good" and not "perfect" and worst of all it used the hated OSI protocol stack (TUBA - TCP & UDP on top of OSI CLNS - also known as IPv9). It even had at least two usable implementations at the time it was proposed (for SunOS and Cisco IOS)

Re: NAT Is the Enemy of Low Power Devices

#50

Post by nolist_policy »

jeroenhd wrote: post #42
pjc50 wrote: post #29

Earlier quoted context omitted.

Shouldn't the VMs have their own MACs?

If they're not routed directly through the network card but use a virtual switch instead, the network upstream only sees the server MAC. If they're directly hooked into the network card they can have their own MACs, but that approach can make it hard to communicate between host and VM.

Also, multiple MACs does not work with wlan.
Post reply on HN