Generic Notification Message for Mobile IPv4
Extracted elements (29)
RFC 5944 provides replay protection only for Registration Requests initiated by the MN; there is no replay protection mechanism for messages initiated by the FA or HA. The 64-bit Identification field in GNM/GNAM is explicitly designed to close this gap for notification messages originating from FA or HA.
The base Mobile IPv4 specification (RFC 5944) has no provision for asynchronous notification messages between HA, FA, and MN outside the Registration Request/Reply exchange. This document fills that gap by defining a generic envelope with well-defined extensibility, rather than requiring separate ad-hoc messages for each notification use case.
The Registration Revocation Message (RFC 3543) is cited as a motivating example of a notification that should have been defined as a GNM extension rather than a standalone message type. Future notifications such as HA switchover, NEMO prefix changes, and load balancing are better served as GNM extensions than as separate messages.
GNMs and GNAMs reuse the same IP/UDP addressing (source/destination addresses and ports) as the prior Registration Request/Reply to the same peer. This design decision enables NAT traversal compatibility and ensures the same security association is used for both registration and notification traffic.
The GNM/GNAM notification mechanism does not support the case of co-located Care-of Address mode with registration through a Foreign Agent (i.e., when the 'R' bit is set in the FA's advertisement messages). Only FA-CoA registration through an FA and direct co-located CoA registration to the HA are supported topologies.
All senders and receivers MUST implement timestamp-based replay protection for the Identification field; nonce-based replay protection is OPTIONAL. A sending node and its receiving node MUST agree on which method to use as part of their mobile security association.
Exactly one authorization-enabling extension MUST be present in a GNM. If no such extension is found, more than one is found, or the Authenticator is invalid, the receiver MUST reject the GNM and SHOULD log the error as a security exception.
GNMs and GNAMs MUST use the same IP source/destination addresses and UDP source/destination ports as the previous Registration Request or Reply exchanged with the peer. This ensures NAT traversal compatibility and that the same security association applies.
GNMs MUST be integrity protected, and replay protection MUST be guaranteed. The 64-bit Identification field provides replay protection for notifications initiated by the FA or HA, filling a gap in RFC 5944 which only provided replay protection for MN-initiated Registration Requests.
If the A bit is set in a GNM but no GNAM is received within a reasonable time, the GNM SHOULD be retransmitted. The minimum time between retransmissions MUST NOT be less than 1 second, and each successive retransmission timeout SHOULD be at least twice the previous period (exponential backoff).
New extensions for use with the Generic Notification Message must be registered with IANA under the 'RFC Required' policy (RFC 5226). A new column is added to the Mobile IPv4 extensions registry to indicate whether each extension is permitted for use with the GNM.
The Identification field in a new GNM MUST NOT be the same as in an immediately preceding GNM, and SHOULD NOT repeat while the same security context is in use, to prevent replay attacks.
The low-order 32 bits of the Identification field MUST be copied unchanged from the GNM into the corresponding GNAM. The receiver MUST verify that these bits in any received GNAM are identical to those sent in the GNM, to correlate responses and detect mismatches.
The MN-HA Authentication Extension is REQUIRED when a GNM or GNAM is exchanged between the MN and HA; the MN-FA AE is REQUIRED between the MN and FA; the FA-HA AE is REQUIRED between the FA and HA. The applicable AE is determined by the MD field value.
The 64-bit Identification field serves dual purposes: matching a GNM to its corresponding GNAM and providing replay protection. When timestamps are used it is formatted as an NTP 64-bit timestamp; when nonces are used the high-order 32 bits carry the receiver's nonce and the low-order 32 bits carry the sender's nonce.
The Generic Notification Acknowledgement Message (GNAM, Type 23) is sent by mobility agents or MNs to indicate successful receipt of a GNM. Its fixed header mirrors the GNM layout but replaces the A flag with a Code field (8 bits) indicating success (0), FA denial (64–69), HA denial (128–133), or MN denial (192–197).
The Generic Notification Message (GNM, Type 22) is a new Mobile IPv4 message that allows HA, FA, and MN to send asynchronous notifications outside the Registration Request/Reply cycle. It carries a Message Direction (MD) field, an 'A' bit for acknowledgement requirement, Home Address, Home Agent Address, Care-of Address, a 64-bit Identification field, and optional extensions.
The MD (Message Direction) field encodes the sender-receiver pair: 0 = HA to MN, 1 = HA to FA, 2 = MN to HA, 3 = MN to FA, 4 = FA to MN, 5 = FA to HA. The MD value determines which authentication extension is required and controls relay behavior at the FA.
A new GNAM Code number space is defined: 0 = notification accepted; 64–69 = error codes from the FA; 128–133 = error codes from the HA; 192–197 = error codes from the MN. Specific codes include authentication failure (67/131/195), ID mismatch (69/133/197), and administrative prohibition (65/129/193). New Code values require expert review.
IANA added a new column to the Mobile IPv4 extensions registry indicating whether each extension is permitted for use with the Generic Notification Message. Currently four extensions are permitted: MN-HA AE, MN-FA AE, FA-HA AE, and the Message String Extension (RFC 4917).
Two new Mobile IPv4 message type numbers are allocated: Type 22 for the Generic Notification Message (GNM) and Type 23 for the Generic Notification Acknowledgement Message (GNAM), from the same number space as Registration Request and Registration Reply.
Nonce-based replay protection uses the high-order 32 bits of the Identification field for the receiver's nonce and the low-order 32 bits for the sender's nonce. Each GNAM carries a new receiver nonce; the sender uses this nonce in its next GNM's high-order bits. The protocol is self-synchronizing: a rejected GNM always yields a fresh nonce in the GNAM.
Timestamp-based replay protection uses the Identification field formatted as a 64-bit NTP timestamp. The receiver checks that the timestamp is close enough to its own clock (default tolerance 7 seconds, SHOULD be greater than 3 seconds) and that it is greater than all previously accepted timestamps from that sender. If the timestamp is invalid, the receiver copies only the low-order 32 bits and returns its own high-order 32 bits for clock re-synchronization, replying with Code 69/133/197.
When the FA relays a GNM between MN and HA without sharing a mobility security association with either peer, non-authentication extensions between the MN-FA or FA-HA pairs are not integrity protected. In this case, all such non-authentication extensions should be silently discarded.
The HA receiving a GNM with MD=5 (from FA): validates FA-HA AE; checks Identification field; processes notification extension; MAY reply with GNAM Code 0. If the HA receives a GNM from an FA and there is no corresponding MN registration, the HA SHOULD drop the GNM.
When an FA receives a GNM with MD=0 it relays it to the MN: it MAY validate the FA-HA AE; if valid (or absent), it MUST relay the GNM to the MN's home address, MUST NOT modify fields up through the MN-HA AE, MUST process and remove extensions after the MN-HA AE, and MAY append its own non-auth extensions followed by MN-FA AE. With MD=1 (FA is target), the FA-HA AE MUST be validated before processing.
When an MN receives a GNM it: (1) checks for exactly one authorization-enabling AE and validates the Authenticator; (2) validates the Identification field against the replay-protection context; (3) checks that all extensions are permitted for GNM use; (4) if all checks pass, processes the message and optionally sends a GNAM with Code 0 if the A bit is set. Failure at any step causes silent discard or rejection with a specific Code.
The GNAM fixed header contains: Type (8 bits, value 23), MD (8 bits), Code (8 bits), Reserved (8 bits), Home Address (32 bits), Home Agent Address (32 bits), Care-of Address (32 bits), and Identification (64 bits). Extensions follow.
The GNM fixed header contains: Type (8 bits, value 22), MD (8 bits, message direction 0–5), A flag (1 bit, acknowledgement required), Reserved (15 bits, sent as 0), Home Address (32 bits), Home Agent Address (32 bits), Care-of Address (32 bits), and Identification (64 bits). Extensions follow the fixed portion.