Update Notifications for Proxy Mobile IPv6
Extracted elements (26)
The protocol fills a gap in base PMIPv6 (RFC5213) which had no mechanism for the LMA to asynchronously notify the MAG about session changes. Existing mechanisms (Heartbeat RFC5847, Binding Revocation RFC5846) were too purpose-specific to serve as a general notification framework.
Using short session lifetimes to force re-registration was considered but rejected as it causes unnecessary signaling load and overhead; demand-based LMA-to-MAG notification is more efficient.
If the MAG does not support UPN messages, it will respond with a Binding Error (Status=2 per RFC6275), which the LMA uses as a signal to stop sending further UPN messages to that MAG.
If the LMA does not receive a UPA for a UPN with the (A) flag set, the LMA MUST retransmit the message with the same Sequence Number and contents, (D) flag set to 1, with a minimum delay of MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY (default 1000ms) and up to MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT (default 1) retransmissions.
If the LMA receives a Binding Error message with Status field 2, it MUST NOT send any further UPN messages to that MAG, as this indicates the MAG does not support the Update Notification message.
If the Notification Reason is ANI-PARAMS-REQUESTED, the MAG MUST send a Proxy Binding Update with the Access Network Identifier option reflecting current access network parameters.
If the Notification Reason is FORCE-REREGISTRATION, the MAG MUST send a Proxy Binding Update to the LMA to renegotiate the mobility session.
If the Notification Reason is UPDATE-SESSION-PARAMETERS and the MAG cannot apply the session parameters, and the (A) flag is set, the MAG MUST send a UPA with status 128 (FAILED-TO-UPDATE-SESSION-PARAMETERS).
Implementations MUST ensure there is no collision between Sequence Numbers of all outstanding Update Notification messages at any time.
The (D) flag MUST be cleared when sending a UPN for the first time for a given Sequence Number; otherwise the sender MUST set this flag to indicate retransmission.
The IPsec SPD entry for protecting Proxy Binding Update and Acknowledgement messages MUST be extended to include Mobility Header Type values 19 and 20 for UPN and UPA messages.
The UPA MUST contain either the Mobile Node Identifier option or the Mobile Node Group Identifier option, copied from the received UPN message.
The UPN message MUST include either the Mobile Node Identifier option (RFC4283) or the Mobile Node Group Identifier option (RFC6602) to identify the mobility session(s) to which the notification applies.
Upon receiving a UPN, the MAG MUST verify that the packet is protected by the same IPsec security association used for protecting other PMIPv6 signaling messages between those peers.
When using IPv4 transport, the source address MUST be set to IPv4-LMAA and destination to IPv4-Proxy-CoA; the Mobility Header is encapsulated in UDP with destination port 5436.
The Notification Reason field defines four values: (1) FORCE-REREGISTRATION, (2) UPDATE-SESSION-PARAMETERS, (3) VENDOR-SPECIFIC-REASON, and (4) ANI-PARAMS-REQUESTED, plus reserved values 0 and 255.
The Update Notification Acknowledgement (UPA) is a Mobility Header message with MH Type value 20, sent by the MAG to acknowledge receipt of a UPN message with the (A) flag set.
The Update Notification (UPN) is a new Mobility Header message with MH Type value 19, sent by the LMA to asynchronously notify the MAG about changes to mobility session parameters.
Two protocol configuration variables are defined: MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT (default 1, range 0-5) and MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY (default 1000ms, range 500-5000ms).
IANA allocated MH Type value 19 for Update Notification and MH Type value 20 for Update Notification Acknowledgement in the 'Mobility Header Types' registry.
IANA created the 'Update Notification Acknowledgement Status Registry' under Mobile IPv6 Parameters, with allocation policy 'Specification Required', defining values 0 (SUCCESS), 128 (FAILED-TO-UPDATE-SESSION-PARAMETERS), and 129 (MISSING-VENDOR-SPECIFIC-OPTION).
IANA created the 'Update Notification Reasons Registry' under Mobile IPv6 Parameters, with allocation policy 'Specification Required', defining values 0 (Reserved), 1 (FORCE-REREGISTRATION), 2 (UPDATE-SESSION-PARAMETERS), 3 (VENDOR-SPECIFIC-REASON), 4 (ANI-PARAMS-REQUESTED), and 255 (Reserved).
UPN and UPA messages MUST be protected using the same IPsec security association used for Proxy Binding Update and Proxy Binding Acknowledgement messages. The existing SA must be reused, not a new one established.
Upon rekeying of the IPsec security association between MAG and LMA, the newly established SA will be used for protecting UPN and UPA messages, ensuring continuity of protection.
The UPA message contains a 16-bit Sequence Number (copied from the UPN), an 8-bit Status Code (0-127 success, 128-255 error), reserved bits, and variable-length Mobility Options.
The UPN message contains a 16-bit Sequence Number, a 16-bit Notification Reason field, a 1-bit Acknowledgement Requested (A) flag, a 1-bit Retransmit (D) flag, reserved bits, and variable-length Mobility Options.