Why not just have the server send a token to the client that the client includes in the next request?
NAT Is the Enemy of Low Power Devices
11–20 of 180 posts
Re: NAT Is the Enemy of Low Power Devices
#12Earlier 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.
That's definitely a limitation of your network. I don't see how ipv6 can shoulder any responsibility here.
Re: NAT Is the Enemy of Low Power Devices
#13Earlier 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.
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.
Re: NAT Is the Enemy of Low Power Devices
#14NAT was an good solution that the IETF came up with, we wouldn't be able to have the internet at our scale without it
Unless IPv6 were to be actually adopted as it was introduced
Re: NAT Is the Enemy of Low Power Devices
#15Earlier 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.
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.
Re: NAT Is the Enemy of Low Power Devices
#16NAT was an good solution that the IETF came up with, we wouldn't be able to have the internet at our scale without it
I'm pretty sure the IETF fought against NAT.
Re: NAT Is the Enemy of Low Power Devices
#17> This doesn’t solve the issue of cloud to device traffic being dropped after NAT timeout (check back for another post on that topic), but for many low power use cases, being able to sleep for an extended period of time is less important than being able to immediately push data to devices.
Is "less important" a typo?
Re: NAT Is the Enemy of Low Power Devices
#18On modern firewalls/routers, NAT is only one cooks in the network kitchen raining on this author's parade. Stateful Packet Inspection has timeouts too!
Re: NAT Is the Enemy of Low Power Devices
#19Why not just have the server send a token to the client that the client includes in the next request?
Because by that point the tcp session is already broken.
Re: NAT Is the Enemy of Low Power Devices
#20The 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 a handful of messages back and forth before actually delivering the data you were interested in sending originally.
The blog post mentions Session IDs as a solution, but these require servers to be stateful, which can be challenging in most deployments. An alternative is Session Tickets (https://datatracker.ietf.org/doc/html/rfc5077), but these may cause issues when offloading networking to another device, such as a cellular modem, as their implementation may be non-standard or faulty.
incoming rant
These issues could be mitigated—or even solved—by using mature software platforms like Zephyr RTOS and their native networking stacks, which receive more frequent updates than traditional “all-in-one-package” SoCs. However, many corporations choose to save a few dollars on hardware at the expense of incurring thousands in software engineering costs and bug-hunting. It is often seen as more cost-effective to purchase a cellular modem with an internal MCU rather than a separate cellular modem and a host MCU to run the networking stack. It is one of the many reasons why many IoT devices are utter garbage.