> This doesn’t solve the issue of cloud to device traffic being dropped after NAT timeout (check back for another post on that topic), This is the key problem.

> This doesn’t solve the issue of cloud to device traffic being dropped after NAT timeout (check back for another post on that topic), This is the key problem. I think it would be best solved by NAT devices having some way of probing their timeout policy, and then notifying the endpoints when they expire a mapping. One way to do that might be for a client to deliberately send a packet to the server with an insufficient TTL. The reply (via ICMP) could then contain fields specifying the timeout in minutes of the mapping, together with some generation number specifying if the mapping table has been cleared due to reboot or overflowed since last queried. There might even be a way to request a specific mapping become long lived - perhaps for months or years. The benefit of all this is that client devices can do push notifications from servers or P2P notifications, all with no polling - allowing for example coin cell devices to last for months or years (with appropriate WiFi protocol improvements too)