The RFC and the implementation are from the same guy.

Heartbeats are used for UDP and other connectionless protocols. TCP doesn't need heartbeats to tell if the connection went down.

I think it can be useful when the TCP connection is going through NAT which may drop the rule and stop passing packets after idling, no?

Yep, crappy routers tend to do this :/

A Juniper MX960 can do NAT. Is that not a router?

If it's configured to do NAT instead of routing, then it's not being a router. Routing is a job and "router" describes a role, not a static property of a box. Like firewall, bridge, etc.

Routing is defined as shuffling packets where they need to go unmolested - without messing with the address or port fields. It's specced in the IP RFC's. If you're mangling the traffic, you're violating router requirements.

You're never seen a router have to do NAT for two subnets that it's routing between?

While I certainly share your dislike of NAT, this is just absurd.

In retrospect, I think using TCP_KEEPALIVE would be a better solution to this specific use case. Are TLS heartbeats truly indistinguishable from normal traffic?

TCP Keepalive is a much better solution for this problem.

Nearly all bitcoin pools utilize TCP keepalive to maintain connections with miners.

These are systems in which performance and DoS resistance are paramount.

My understanding, from the heartbleed page, is that the packets for the heartbeat have a specific packet type identifier and that you can use this to train an IDS to watch for the heartbleed attack.

I would guess that makes them identifiable?

Sure it does. SSH to a remote host, do nothing, then disconnect the cable connected to your router's uplink. SSH (for example) won't notice as long as you do nothing in your SSH session.

On some connections where I have SSH keepalives disabled, I can suspend my laptop, go for a drive around town with it, come home, resume, and still have my session connected.

Yup. But probably wise to run screen or tmux to avoid processes on the other end getting HUPed in case of romantic interludes, etc.

TCP absolutely needs a heartbeat/keepalive to tell if the connection went down. There is no way to distinguish between no traffic being sent and session going down uncleanly. It's very common that some NAT drops the binding of an idle TCP connection and the peers don't discover that until their timeouts expire (could be anything from minutes to hours).

If you want to know if the connection went down in a reasonable timeframe e.g tens of seconds, then you need to implement heartbeating over TCP. This is the first thing any new protocol on TCP usually does.

That is theory but not practically correct. http://0xdata.com/blog/2013/08/tcp-is-not-reliable/

What is not necessary for a TCP heartbeat is a payload that would address out of order request/reply sequence (as would be necessary in UDP).

the IETF stands for Internet Engineering Task Force. They are the people who design protocols that run the internet. Note however that you don't necessarily have to listen to them, it's more like a defacto standard. Also they have nothing to do with implementing them necessarily.