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

81–90 of 180 posts

Re: NAT Is the Enemy of Low Power Devices

#81

Post by pwdisswordfishz »

marsven_422 wrote: post #23
vv_ wrote: post #20

The problem(-s) described in the blog post are really acute for IoT in general, especially if you want your device to run on batteries or you have a limited data budget. > Therefore, when you try to continue talking to the server over a previously established session, it will not recognize you. This means you’ll have to re-establish the session, which typically involves expensive cryptographic operations and sending…

[flagged]

Is it used by the army of Israel against civilians? Because I can't think of any other circumstance that would justify such a strong condemnation.

Re: NAT Is the Enemy of Low Power Devices

#82

Post by Joel_Mckay »

jeroenhd wrote: post #44
elcritch wrote: post #28

Earlier quoted context omitted.

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 r…

A dual core 240MHz cpu with hardware paged flash and spi ram expansion support is not "small" in my opinion.

However, I am a fan of their price point for hobby projects. Best regards =3

Re: NAT Is the Enemy of Low Power Devices

#83

Post by eythian »

Hikikomori wrote: post #55
jeroenhd wrote: post #47

Earlier quoted context omitted.

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…

Does it matter if they rotate if you use prefix delegation with standard size?

It depends what you're trying to defend against. The rotation hinders associating an address with a particular device. If someone looks at the network prefix to see if people are in the same household, then that's exactly the same as looking at the IPv4 address to determine the same thing.

Re: NAT Is the Enemy of Low Power Devices

#84

Post by eythian »

fc417fc802 wrote: post #60
Hikikomori wrote: post #55

Earlier quoted context omitted.

Does it matter if they rotate if you use prefix delegation with standard size?

No, it doesn't. At least the last time I checked unless you go out of your way to implement a non-standard configuration IPv6 is a disaster for personal privacy for the typical multi-user household. Then again, the "typical" multi-user household is likely logged in to most things via SSO with Google or Facebook and probably has approximately zero fingerprinting mitigations in use so perhaps it isn't worth worrying ab…

> IPv6 is a disaster for personal privacy for the typical multi-user household

Why? With privacy extensions (which are normally enabled for user devices), then all someone can do is look at the prefix. This is identical to looking at the IPv4 address in a NAT setup, and it hasn't been that much of a privacy disaster.

As I see it, nothing is lost on that front.

Re: NAT Is the Enemy of Low Power Devices

#85

Post by marsven_422 »

shipp02 wrote: post #32
SirSavary wrote: post #30

Earlier quoted context omitted.

Could you elaborate for someone who is unfamiliar?

Zephyr RTOS[1] is an RTOS supported by the Linux foundation. It has similar structures to Linux for device configuration like a device tree and tries to emulate POSIXish APIs. I think some embedded people are put off by this configuration structure. Notably, Zephyr RTOS is the basis of Nordic Semiconductor's SDK[2]. Nordic is a major manufacturer of cellular and wireless MCUs. [1]: https://www.zephyrproject.org/ [2]:…

[dead]

Re: NAT Is the Enemy of Low Power Devices

#86

Post by api »

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.

You can do local NAT. Most VM hosts will do it. You just don’t need NAT everywhere anymore.

Re: NAT Is the Enemy of Low Power Devices

#87

Post by somanyphotons »

wmf wrote: post #15
Dylan16807 wrote: post #13

Earlier quoted context omitted.

Are you talking about eliminating NAT on IPv4? IPv6, set up the normal way, does not allocate IPs. Devices can and will have several at once and their VMs can easily get some too.

The enterprise corrupted IPv6 and disabled SLAAC so devices have to use whatever DHCPv6 gives them.

How does that work for android devices? I heard they don't allow dhcp provided addresses?

Re: NAT Is the Enemy of Low Power Devices

#88

Post by glowing12131 »

hasheddan wrote: post #71
vv_ wrote: post #68

Earlier quoted context omitted.

Power Saving Mode (PSM), a power-saving mechanism in LTE, was specifically designed to address such issues. It allows the device to inform the eNB (base station) that it will be offline for a certain period while ensuring it periodically wakes up to perform a Tracking Area Update (TAU), preventing the loss of registration. This concept is similar to Session Tickets or Session IDs in (D)TLS—or at least, that’s how I l…

Great pointer! My sibling post in this thread references a few other blog entries where we have detailed using eDRX and similar low power modes alongside Connection IDs. I agree that many devices don't need to be immediately responsive to cloud to device communication, and checking in for firmware updates on the order of days is acceptable in many cases. One way to get around this in cases where devices need to be fa…

Is "Non-IP Data Delivery" (basically SMS but for raw data packets, bound to a pre-defined application server) already a thing in practice?

In theory, you get all the power saving that the cellular network stack has to offer without having to maintain a connection. While on protocol layer NIDD is almost handled like an SMS (paging, connectionless), it is not routed through a telephony core (and hence sloooow). The base station / core will directly forward it to your predefined application server.

Re: NAT Is the Enemy of Low Power Devices

#89

Post by phendrenad2 »

vollbrecht wrote: post #45
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

"not any protection whatsoever" is way too strong a statement. NAT does raise the bar to exploiting a random smart lightbulb in your house significantly higher.

Re: NAT Is the Enemy of Low Power Devices

#90

Post by wmf »

somanyphotons wrote: post #87
wmf wrote: post #15

Earlier quoted context omitted.

The enterprise corrupted IPv6 and disabled SLAAC so devices have to use whatever DHCPv6 gives them.

How does that work for android devices? I heard they don't allow dhcp provided addresses?

The Android problem only occurs in an IPv6-only enterprise network which is very rare. Otherwise Android can use IPv4.
Post reply on HN