Heartbeat Mechanism for Proxy Mobile IPv6
Extracted elements (27)
An unsolicited Heartbeat Response (U bit set) is sent immediately after restart to allow peers to discover the recovery quickly, rather than waiting up to HEARTBEAT_INTERVAL seconds for the next periodic exchange. The sequence number in such a message is ignored since synchronization occurs in the subsequent request/response cycle.
Heartbeat messages are defined as a subtype of the existing Mobility Header (protocol 135) rather than a new protocol, so the existing IPsec security policy infrastructure for PMIPv6 can protect them by simply adding MH Type 13 as an SPD selector — no new security mechanisms are required.
The Restart Counter is preserved across reboots (as persistent state) so that a restarted node can correctly signal its recovery to peers, even when it has lost all PMIPv6 session state — without persistent storage the counter would reset to a previously seen value and the peer could not detect the restart.
A PMIPv6 node that does not support Heartbeat messages responds with a Binding Error (status 2, unrecognized MH type), per RFC 3775. The initiating node MUST cease sending Heartbeat messages to that peer upon receiving this error.
When the network between MAG and LMA is IPv4-only, Heartbeat messages are transported as specified in RFC 5844: the Mobility Header is carried as the UDP payload inside an IPv4 packet (IPv4-UDP-MH encapsulation).
A Heartbeat Request message SHOULD NOT be sent if the MAG has no proxy Binding Cache entries at the LMA for any mobile node attached to it. Similarly, the LMA SHOULD NOT send a Heartbeat Request to a MAG if there is no active Binding Cache entry created by that MAG.
A PMIPv6 node MUST respond to a Heartbeat Request message with a Heartbeat Response message, irrespective of whether there is an active Binding Cache entry.
Each PMIPv6 node (both MAG and LMA) MUST maintain a monotonically increasing Restart Counter that is incremented every time the node reboots and loses PMIPv6 session state. This counter MUST be treated as state preserved across reboots.
Each PMIPv6 node MUST store the Restart Counter for all peer PMIPv6 nodes with which it currently has sessions; stored values for peer nodes do not need to be preserved across reboots.
If a PMIPv6 node restarts and loses PMIPv6 session state, it SHOULD send an unsolicited Heartbeat Response message with an incremented Restart Counter to all PMIPv6 nodes that had previously established sessions.
Integrity protection using IPsec [RFC4301] for the Heartbeat messages MUST be supported on the MAG and the LMA.
The HEARTBEAT_INTERVAL SHOULD NOT be configured to a value less than 30 seconds to avoid creating overhead, congestion, or degraded network performance on the path between the MAG and the LMA.
The MH Type field in the Mobility Header for a Heartbeat message MUST be set to 13.
The Restart Counter MUST NOT be incremented if recovery happens without losing state for the PMIPv6 sessions active at the time of failure, ensuring the counter only signals stateful restarts.
The Type field of the Restart Counter mobility option MUST be set to 28.
When a Binding Error message with status set to 2 (unrecognized MH type) is received in response to a Heartbeat Request, the initiating MAG or LMA MUST NOT use Heartbeat messages with that peer again.
MISSING_HEARTBEAT is a local counter incremented each time a Heartbeat Response is not received before the next request. When it exceeds MISSING_HEARTBEATS_ALLOWED, the peer is declared unreachable; it resets to zero upon receipt of a valid Heartbeat Response.
The Heartbeat message is a Mobility Header message (protocol type 135, MH Type 13) periodically exchanged between MAG and LMA. It contains a Reserved field, a U bit (unsolicited response), an R bit (request=0/response=1), a 32-bit Sequence Number, and variable-length Mobility Options.
The Restart Counter Mobility Option is a TLV option valid only in Heartbeat Response messages, with alignment requirement of 4n+2. It carries a 32-bit Restart Counter value, with Type=28 and Length=4.
IANA allocated MH Type value 13 for the Heartbeat message from the Mobility Header MH Type name space originally defined in RFC 3775.
IANA allocated mobility option Type value 28 for the Restart Counter mobility option from the mobility options name space originally defined in RFC 3775.
Heartbeat messages carry no sensitive data useful to eavesdroppers, so confidentiality protection is not required. However, IPsec integrity protection MUST be supported and should be enforced via SPD entries using the new MH Type 13 selector.
If dynamic key negotiation between the MAG and the LMA is required, IKEv2 [RFC4306] should be used, consistent with the security model already established for PMIPv6 signaling in RFC 5213.
Failure detection: a PMIPv6 node sends Heartbeat Requests every HEARTBEAT_INTERVAL seconds, increments MISSING_HEARTBEAT on each unanswered request, resets it on a valid response, and transitions to 'peer unreachable' state when MISSING_HEARTBEAT exceeds MISSING_HEARTBEATS_ALLOWED.
Restart detection: upon receiving a Heartbeat Response, the node compares the included Restart Counter to the stored value. If different (or no prior value), it assumes the peer crashed and recovered, stores the new counter, and signals the restart to the local PMIPv6 stack.
The Heartbeat message body (following the Mobility Header Checksum field) consists of: 14-bit Reserved + U flag (1 bit) + R flag (1 bit) = 16 bits total for the first word, followed by a 32-bit Sequence Number, then variable-length Mobility Options padded to a multiple of 8 octets.
The Restart Counter Mobility Option encodes: Type (8 bits, value 28), Length (8 bits, value 4), and Restart Counter (32 bits), totaling 6 octets with 4n+2 alignment.