https://www.rfc-editor.org/rfc/rfc6520 does not explain why a heartbeat request/response round-trip is supposed to contain a payload. It just specifies that there is room for payload and that the response has to contain the same payload as the request.
What is this payload good for? My questions are:
What could it be that the engineers thought when they designed the protocol to allow for including arbitrary payload into the heartbeat request? What are the advantages?
What are the reasons that this payload must be contained in the response?
I see that by allowing for arbitrary payload the application is able to unambiguously match a certain response with a certain request. Is that the only advantage? If yes, then why did one not force the payload to be of a certain length? What is the flexibility in the payload length good for? Does it have to do with a cryptographic concept, such that the length of heartbeat requests must be unpredictable?
Other "heartbeat"-like protocol extensions simply pre-define the exact request (e.g. "ping") and the corresponding response (e.g. "pong"). Why did https://www.rfc-editor.org/rfc/rfc6520 take a different route?
It is important to understand the reasoning behind the choices made in RFC6520 in order to properly assess hypotheses that all this might have been an intelligently placed backdoor.
pingcommand-line utility uses to find out whether or not a server is alive, and every IP-enabled device ever made implements it. So this arbitrary-payload concept goes back to at least 1981. I could make an educated guess as to why, but I couldn't dig up any authoritative sources. – Daw