RFC 6098

Generic Notification Message for Mobile IPv4

📅 published April 2012, from ietf

RFC 6098 🎀 Generic Notification Message for Mobile IPv4 💖

The Internet Engineering Task Force (IETF) put this one out in April 2012, and it's a Standards Track document, so it's official protocol stuff. 🌸 The authors are H. Deng (China Mobile), H. Levkowetz (Netnod), V. Devarapalli (Vasona Networks), S. Gundavelli (Cisco), and B. Haley (Hewlett-Packard Company). ISSN: 2070-1721. The title block doesn't list anything it obsoletes or updates. 👀

Table of Contents ✨

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Notification Message - Usage Scenarios ..........................4
      3.1. Notification Message - Examples ............................4
      3.2. Notification Message - Topology ............................5
           3.2.1. Notification Message between a Home Agent
                  and a Mobile Node ...................................6
           3.2.2. Notification Message between a Foreign Agent
                  and a Mobile Node ...................................6
           3.2.3. Notification Message between a Home Agent
                  and a Foreign Agent .................................7
   4. Generic Notification Message and Considerations .................7
      4.1. Generic Notification Message ...............................7
      4.2. Generic Notification Acknowledgement Message ..............11
      4.3. Notification Retransmission ...............................14
      4.4. General Implementation Considerations .....................15
      4.5. Mobile Node Considerations ................................15
           4.5.1. Receiving Generic Notification Messages ............15
           4.5.2. Sending Generic Notification
                  Acknowledgement Messages ...........................16
           4.5.3. Sending Generic Notification Messages ..............17
           4.5.4. Receiving Generic Notification
                  Acknowledgement Messages ...........................18
      4.6. Foreign Agent Consideration ...............................18
           4.6.1. Receiving Generic Notification Messages ............19
           4.6.2. Sending Generic Notification
                  Acknowledgement Messages ...........................21
           4.6.3. Sending Generic Notification Messages ..............21
           4.6.4. Receiving Generic Notification
                  Acknowledgement Messages ...........................22

      4.7. Home Agent Consideration ..................................23
           4.7.1. Sending Generic Notification Messages ..............23
           4.7.2. Receiving Generic Notification
                  Acknowledgement Messages ...........................24
           4.7.3. Receiving Generic Notification Messages ............24
           4.7.4. Sending Generic Notification
                  Acknowledgement Messages ...........................26
   5. Future Extensibility ...........................................26
      5.1. Examples of Possible Extensions ...........................26
      5.2. Extension Specification ...................................27
   6. IANA Considerations ............................................28
   7. Security Considerations ........................................28
      7.1. Replay Protection for GNMs and GNAMs ......................29
           7.1.1. Replay Protection Using Timestamps .................29
           7.1.2. Replay Protection Using Nonces .....................30
      7.2. Non-Authentication Extensions Handling in the
           Foreign Agent .............................................31
   8. Acknowledgements ...............................................31
   9. References .....................................................32
      9.1. Normative References ......................................32
      9.2. Informative References ....................................32

Abstract 🦋

This doc is all about protocol enhancements that let Mobile IPv4 entities send and receive explicit notification messages, using a Mobile IPv4 message type that was made specifically for this job. 💜

Status of This Memo 📜

This is an Internet Standards Track document. 🌈

It's a product of the Internet Engineering Task Force (IETF), so it totally represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741. 💅

Info about this doc's current status, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6098. 🔍

Copyright Notice ⚖️

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 🫶

This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person or people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So, unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC and translating it into languages other than English. 🌸

1. Introduction ✨

Sometimes Mobile IPv4 entities, like the home agent (HA), foreign agent (FA), and mobile node (MN), need to send and receive asynchronous notification messages during a mobility session. Here, "asynchronous messages" means messages that aren't synchronous with the Registration Request and Registration Reply messages from the base Mobile IP (MIP) specification [RFC5944]. And the base Mobile IP spec has no provision for this, which is the whole problem. 😭

To fix that, this document defines a generic notification message and a notification model that Mobile IPv4 entities can use to send all sorts of notifications. It also defines a matching acknowledgement message, so delivery can be made reliable. 🔥 Only the following extensions may be present in these new messages, as this document defines them:

MN-HA Authentication Extension
MN-FA Authentication Extension
FA-HA Authentication Extension
Message String Extension

Receiving a generic notification message with a Message String Extension has null semantics. In other words, it has no effect on the state of a mobile node's existing registration. 🧚 See Section 3.1 for some application examples that motivate the new messages defined in this document.

2. Terminology 📖

You're assumed to be familiar with the terminology used in [RFC4917] and [RFC5944]. On top of that, this doc often uses these terms: 💜

Notification Message

A message from a mobility agent to an MN or another mobility agent, or from an MN to a mobility agent, that asynchronously notifies the recipient about an event relevant to the mobility service it's currently providing.

Generic Notification Message

A Notification Message in the context of Mobile IPv4 that has a well-defined envelope format and extensibility, with certain limitations on how extensions may be defined and used. Otherwise it's generally available for notification purposes within the Mobile IPv4 protocol. Abbreviated 'GNM' in this document. 🦋

Generic Notification Acknowledgement Message

An acknowledgement of a received Generic Notification Message. Abbreviated 'GNAM' in this document. 🌈

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🙈

3. Notification Message - Usage Scenarios 🎀

3.1. Notification Message - Examples 💌

The simplest use case for a notification message is when the notification has no semantic meaning inside the protocol. It's just carrying a message that can be shown to a user or an operator, depending on which one is the receiving entity (more on this in Section 3.2 below). Examples are messages from operator to user about billing or service events, like "You have used nearly all of your prepaid quota; there are only XX MB left -- please purchase further service if you are going to need it." or "You have now used data transfer services for the amount of $XXX since your last bill; this is above the notification threshold for your account." Messages about service interruptions are another example, and there are more. All of these are supported by the Mobile IPv4 Generic Notification Message together with the Message String Extension, as defined in this document. 💖

There are also other examples that can't be implemented using only the messages and extensions defined in this document. A few of these are described briefly below, and Section 5 covers them a bit more thoroughly. 🫶

One example of an extended Generic Notification Message: during handover between CDMA 2000 1x EV-DO and Wireless LAN, the PPP resource on the CDMA side has to be removed on the FA (Packet Data Serving Node) to avoid over-charging subscribers. The Registration Revocation Message was defined in [RFC3543] to handle this. But it would have been nicer to have it defined as a separate message (the Generic Notification Message) with a Registration Revocation extension. 😭

Other applications are:

HA switch-over (before the HA decides to go offline, it would like to notify the MNs to register with another candidate HA)
Network Mobility (NEMO) prefix changes (an MN is notified by the HA about NEMO prefix changes and service- or billing-related events; this is an operational requirement)
load balancing (the HA wants to move some of the registered MNs to other HAs)
service termination (due to end of prepaid time)
service interruption (due to system maintenance)

3.2. Notification Message - Topology 🗺️

There are several scenarios where a mobility agent could start notification events. Some of them are described in the following sections. 🧚

3.2.1. Notification Message between a Home Agent and a Mobile Node 🦋

3.2.1.1. Mobile Registered Using a Foreign Agent Care-of Address 🧚

Okay so in this case the HA can't just notify the MN directly 🥺 It has to send the notification through the FA, and it works the other way around too, MN to HA via the FA 💅

           +----+    notification  +----+ notification  +----+
           | MN |<================>| FA |<=============>| HA |
           +----+                  +----+               +----+

           Figure 1: HA notifies MN or MN notifies HA through FA

3.2.1.2. Mobile Registered Using a Co-Located Care-of Address 🦋

Now this one is giving direct line! The MN has registered with the home agent itself, so the notification can go straight to the MN ✨

Heads up though, bestie ⚠️ the notification mechanism as specified here does not support co-located Care-of Address (CoA) mode with registration through an FA. That's because the 'R' bit is set in the FA's advertisement messages, so this combo is a no-go 🙅‍♀️

           +----+             notification            +----+
           | MN |<===================================>| HA |
           +----+                                     +----+
       Figure 2: HA directly notifies MN or MN directly notifies HA

3.2.2. Notification Message between a Foreign Agent and a Mobile Node 💌

Okay so there are two situations where an FA can send notification messages to an MN 👀 In the first one, it's just relaying a message. In the second one, the notification gets triggered by a message from some other network entity, like an Authentication, Authorization, and Accounting (AAA) node. (Notification messages between an AAA entity and the FA could be based on RADIUS or Diameter, but that's out of scope for this document, so we're not going there 🙈) And if the FA starts the notification itself, it might also need to tell the HA about the event 🫶

   +----+    notification  +----+    trigger   +--------+
   | MN |<================>| FA |<=============|   AAA  |
   +----+                  +----+              +--------+
                             ||   notification +----+
                              ================>| HA |
                                               +----+

                         Figure 3: FA notifies MN

3.2.3. Notification Message between a Home Agent and a Foreign Agent 🌸

The HA might also need to send a notification to the FA, but not to the MN 💜 And the FA might need to send one back to the HA. Here's the vibe:

                       +----+ notification  +----+
                       | FA |<=============>| HA |
                       +----+               +----+

                Figure 4: HA notifies FA or FA notifies HA

4. Generic Notification Message and Considerations ✨

Okay this section is the main event 👑 It goes deep into the Generic Notification Message (GNM), the Generic Notification Acknowledgement Message (GNAM), and some considerations for how the MN, FA, and HA handle these messages.

Before anything else, the MN and HA MUST maintain the following information:

the IP source address of the Registration Request/Reply
the IP destination address of the Registration Request/Reply
the UDP source port of the Registration Request/Reply
the UDP destination port of the Registration Request/Reply

The sending node always sends the GNM using the same procedure it uses for a Registration Request, as in Section 3.3 of [RFC5944]. The receiving node follows the same procedure it uses for a Registration Reply, as in Section 3.4 of [RFC5944], when it sends the GNAM 🎀

4.1. Generic Notification Message 💖

A GNM is sent by a mobility agent to tell another mobility agent, or an MN, about MIP-related information. It goes in the form of a Message String Extension [RFC4917] ✨ These messages MUST use the same IP and UDP headers as any previous Registration Request (RRQ) or Reply (RRP) message to the same entity. Why? Because that supports NAT traversal and makes sure GNM/GNAM uses the same security association as RRQ/RRP 🔐 The GNM is defined like this:

IP Fields:

Source Address

Typically, copied from the destination address of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.

Destination Address

Copied from the source address of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.

UDP Fields:

Source Port

Typically, copied from the destination port of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.

Destination Port

Copied from the source port of the last Registration Reply/Request message that the agent received from the agent to which it is sending the GNM.

The UDP header is followed by the Mobile IP fields shown below 🧚

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      MD       |A|  Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Home Agent Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Identification                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+

Type 22 🍓

MD: Message Direction 🧭

This memo defines the meaning of these MD field values:

0 -- Message sent by the HA to the MN
1 -- Message sent by the HA to the FA
2 -- Message sent by the MN to the HA
3 -- Message sent by the MN to the FA
4 -- Message sent by the FA to the MN
5 -- Message sent by the FA to the HA

This bit tells you whether the recipient MUST acknowledge the notification message. If the "A" bit was set on the message but the sender doesn't get an acknowledgement, then the sender will have to re-send the notification message again 🔁

Set to "1" to indicate that acknowledgement is REQUIRED.

Set to "0" to indicate that acknowledgement is OPTIONAL.

Reserved

It MUST be sent as 0, and ignored when received 🙈

Home Address

The home address of the mobile node 🏠

Home Agent Address

The IP address of the mobile node's HA 📍

Care-of Address

The mobile node's care-of address, either the co-located care-of address or the foreign agent care-of address 🚐

Identification

A 64-bit number, constructed by the sender. It's used for matching GNM with GNAM and for protecting against replay attacks of notification messages 🛡️ See Sections 7.1.1 and 7.1.2 for more on how timestamps and nonces get used in this field. Support for timestamps is REQUIRED, and support for nonces is OPTIONAL. Timestamps are the must-have, nonces are the extra-cute bonus 💅

Extensions

The fixed part of the GNM is followed by one or more extensions that may be used with this message, plus one or more authentication extensions as defined in Section 3.5 of [RFC5944] 🧩

Apart from the Authentication Extensions mentioned below, only one extension is defined in this document as permitted for use with the GNM: the Message String Extension defined in [RFC4917].

This document requires the MN-HA Authentication Extension (AE) to be used when this message is sent between the MN and the HA. MN-FA AE and FA-HA AE are OPTIONAL. This document also requires the use of the MN-FA AE when this message is sent between the MN and the FA, and the MN-HA AE and FA-HA AE are not needed there. This document finally requires the use of the FA-HA AE when this message is sent between the FA and the HA, and the MN-HA AE and MN-FA AE are not needed then. This could be determined based on the "MD" value. See Sections 3.6.1.3 and 3.8.3.3 of [RFC5944] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules are applicable to GNM and GNAM 🌈

4.2. Generic Notification Acknowledgement Message ✨

okay so the GNAM is the little "got it, bestie!" reply 🫶. Mobility agents or MNs send it to confirm they successfully received a GNM.

IP Fields:

Source Address: typically, copied from the destination address of the GNM the agent is replying to 🌸
Destination Address: copied from the source address of that same GNM 🦋

UDP Fields:

Source Port: copied from the destination port of the corresponding GNM 💜
Destination Port: copied from the source port of the corresponding GNM ✨

The UDP header is followed by the Mobile IP fields. Here's the layout 👑

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |      MD       |     Code      | Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Home Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home Agent Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Care-of Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Identification                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Extensions...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

Type 23 💅

MD (Message Direction): this memo defines these values, and they're the whole vibe of who's talking to who 🧚
- 0 -- Message sent by the HA to the MN
- 1 -- Message sent by the HA to the FA
- 2 -- Message sent by the MN to the HA
- 3 -- Message sent by the MN to the FA
- 4 -- Message sent by the FA to the MN
- 5 -- Message sent by the FA to the HA
Code: a value showing the result of the GNM. The currently defined Code values are below 🍓

Notification successful

0 -- notification accepted

Notification denied by the HA

128 -- reason unspecified
129 -- administratively prohibited
130 -- insufficient resources
131 -- mobile node failed authentication
132 -- foreign agent failed authentication
133 -- notification Identification mismatch

Notification denied by the FA

64 -- reason unspecified
65 -- administratively prohibited
66 -- insufficient resources
67 -- mobile node failed authentication
68 -- home agent failed authentication
69 -- notification Identification mismatch

Notification denied by the mobile node

192 -- reason unspecified
193 -- administratively prohibited
194 -- insufficient resources
195 -- foreign agent failed authentication
196 -- home agent failed authentication
197 -- notification Identification mismatch
Home Address: the home address of the mobile node 🏡
Home Agent Address: the IP address of the sender's home agent 💖
Care-of Address: the mobile node's care-of address, which is either the co-located care-of address or the foreign agent care-of address 🌈
Identification: a 64-bit number that matches the GNM with the GNAM and protects against replay attacks of notification messages. See Sections 7.1.1 and 7.1.2 for more on how timestamps and nonces go in this field. Support for timestamps is REQUIRED, and support for nonces is OPTIONAL. The value is based on the Identification field from the sender's GNM, plus the style of replay protection used in the security context between the sender and its receiver (defined by the mobility security association between them, and the Security Parameter Index (SPI) value in the authorization-enabling extension) 🔥
Extensions: the fixed portion of the GNAM is followed by one or more extensions that may be used with this message, and by one or more authentication extensions as defined in Section 3.5 of [RFC5944].

This document REQUIRES the MN-HA Authentication Extension (AE) when this message is sent between the MN and the HA. The MN-FA AE and FA-HA AE are OPTIONAL. This document also requires the MN-FA AE when this message is sent between the MN and the FA, and the MN-HA AE and FA-HA AE aren't needed there. Finally, this document requires the FA-HA AE when this message is sent between the FA and the HA, and the MN-HA AE and MN-FA AE aren't needed there. You can figure out which one applies from the "MD" value. See Sections 3.6.1.3 and 3.8.3.3 of [RFC5944] for the rules on the order of these extensions as they appear in Mobile IPv4 RRQ and RRP messages. The same rules apply to GNM and GNAM 🦋

4.3. Notification Retransmission ⏰

if the "A" flag was set in the GNM but the sender doesn't get any GNAM within a reasonable time, then the GNM SHOULD be retransmitted. With timestamps, each retransmission gets a brand-new notification Identification, so it counts as a new GNM. With nonces, the unanswered GNM goes out unchanged, so the retransmission doesn't count as a new GNM (Section 7.1). This way, a retransmission doesn't force the receiver to re-synchronize with the sender by issuing another nonce, even if the original GNM (rather than its GNAM) got lost in the network 🧸

The maximum time until a new GNM is sent SHOULD be no greater than the requested Lifetime of the last GNM. The minimum value SHOULD be large enough to cover the size of the messages, twice the round-trip time for transmission to the receiver, and at least an additional 100 milliseconds for processing the messages before responding. The round-trip time for transmission to the receiver will be at least as large as the time REQUIRED to transmit the messages at the link speed of the sender's current point of attachment. Some circuits add another 200 milliseconds of satellite delay to the total round-trip time to the receiver 🛰️ The minimum time between GNMs MUST NOT be less than 1 second. Each successive retransmission timeout period SHOULD be at least twice the previous period, as long as that stays under the maximum specified above 💅

4.4. General Implementation Considerations 🛠️

Implementations of this specification should support managing the various settings for the notification messages. In particular, it should be possible to do the following:

List the notification messages supported.
Show enabled/disabled status for notification message support, both overall and in detail.
Show the values of the maximum and minimum retransmission times.
Enable and disable notification support entirely.
Enable and disable the individual notification messages supported.
Set the values of the maximum and minimum retransmission times described in Section 4.3.

4.5. Mobile Node Considerations 📱

It's possible that the MN MAY receive a GNM from an FA or HA. For both the FA-CoA and co-located CoA cases, the MN MAY reply with a GNAM based on the "A" flag in the GNM 💖

4.5.1. Receiving Generic Notification Messages 🎀

When the MN is using an FA-CoA and receives a notification message, if the "MD" value is 0, the notification came from the HA. If the "MD" value is 4, it came from the FA. If the MN is using a co-located CoA and receives a notification message, the "MD" value will be 0, meaning it came from the HA 🦋

The MN MUST check for the presence of an authorization-enabling extension and perform the indicated authentication. Exactly one authorization-enabling extension MUST be present in the GNM.

If this message came from an FA, then an MN-FA AE MUST be present. If no MN-FA AE is found, if more than one MN-FA AE is found, or if the Authenticator is invalid, then the MN MUST reject the GNM and MAY send a GNAM to the FA with Code 195, including an Identification field computed according to the rules in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception 🚨

If this notification message came from the HA, relayed by the FA, or if the MN is using a co-located CoA, then the MN-HA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, if more than one MN-HA AE is found, or if the Authenticator is invalid, then the MN MUST reject the GNM and MAY send a GNAM to the initiator with Code 196, including an Identification field computed according to the rules in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception 😭

The MN MUST check that the Identification field is correct using the context selected by the SPI within a mandatory authentication extension like the MN-FA AE or MN-HA AE. See Section 7.1 for how this is done. If it's incorrect, the MN MUST reject the GNM and MAY send a GNAM to the initiator with Code 197, including an Identification field computed according to the rules in Section 7.1. The MN MUST do no further processing with such a notification, though it SHOULD log the error as a security exception 💀

The MN MUST also check that the extensions present in the Generic Notification Message are permitted for use with the GNM. If they aren't, the MN MUST silently discard the message. It MUST NOT do any further processing with such a notification, though it SHOULD log the error 🙈

If the MN accepts a GNM, it processes it according to the specific rules for the extensions. After that, the MN MAY reply to the originator with a GNAM with Code 0 based on the "A" flag in the GNM ✨

4.5.2. Sending Generic Notification Acknowledgement Messages ✨

Okay bestie, so whether the MN is using a co-located CoA or an FA-CoA, it MAY reply with a GNAM, and the "A" flag in the GNM is what decides it 💅 Here's how the MN handles each case 🎀

If the GNM came from the FA to the MN ("MD" value is set to 4), then the MN-FA AE MUST be the last extension, so that it protects every other non-authentication extension. That's the rule from Section 3.5.3 of [RFC5944] 🔒 In the FA-CoA case, the source address is the MN's address and the destination address is the FA's address 🦋

The Code field of the GNAM follows the rules in Section 4.2. When the MN accepts a notification, it SHOULD respond with Code 0 🌸

Sometimes the MN has to say no, and there are a few reasons it might. It could be not allowed to receive notifications at all, which is the vibe of Code value 193 (administratively prohibited). It could be unable to act on or display the notification, or just running low on resources, which gets Code value 194 (insufficient resources) 💀 And if none of the specific codes fit, the MN uses Code value 192 (reason unspecified) 🙈

If the GNM was initiated from the HA to the MN ("MD" value is set to 0) and the MN has a co-located CoA, then the MN-HA AE MUST be the last extension, which keeps all the other non-authentication extensions protected. See Section 3.5.2 of [RFC5944] for that one ✨

When the MN replies to a GNM from an HA with an FA-CoA, the source address is the MN's home address and the destination address is the FA's address ("MD" value is set to 2). The extension order here is giving layers 🧁: any non-authentication Extensions meant for the HA go first, then the MN-HA AE from Section 3.5.2 of [RFC5944], then any non-authentication Extensions meant for the FA, and finally the MN-FA AE from Section 3.5.3 of [RFC5944] 👑

4.5.3. Sending Generic Notification Messages 🧚

The MN may send a GNM to notify either the FA or the HA, whichever one needs to hear it 🍓

If the message goes to the FA, the source address is the MN's address and the destination address is the FA's address. If the FA is the actual target of the notification, then the "MD" value is set to 3, and the MN-FA AE MUST be the last extension so it protects all the other non-authentication extensions 🛡️ Computing the Authentication Extension Values works the same way as in Section 3.5.1 of [RFC5944] 💜

If the FA is only acting as a relay agent, the "MD" value is set to 2. The extension order is: the notification extension first, then any non-authentication extension the HA is expecting, then the MN-HA AE from Section 3.5.2 of [RFC5944], then any non-authentication Extensions meant for the FA, and last the MN-FA AE from Section 3.5.3 of [RFC5944]. Authentication Extension Values are computed the same way as in Section 3.5.1 of [RFC5944] ✨

With a co-located CoA, the MN MAY send a notification message directly to the HA if it needs to notify it. Here the "MD" value is set to 2, and the order is: the notification extension, then any non-authentication extension the HA is expecting, then the MN-HA AE from Section 3.5.2 of [RFC5944] 🦋

The MN picks the Identification field based on the style of replay protection it uses with its HA. That's part of the mobility security association the MN shares with its HA, so it's a whole vibe 🔐 See Section 7.1 for how the MN actually computes the Identification field 🎀

4.5.4. Receiving Generic Notification Acknowledgement Messages 🫶

In the FA-CoA case, if the MN gets this message and the "MD" value is set to 0, then the GNAM came from the HA 🏠

If the "MD" value is set to 4, the MN-FA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If there's no MN-FA AE, or more than one MN-FA AE, or the Authenticator is invalid, then the MN MUST silently discard the GNAM. Hard no 🙅‍♀️

Also, the low-order 32 bits of the Identification field in the GNAM MUST be compared to the low-order 32 bits of the Identification field in the most recent GNM sent to the replying agent. If they don't match, the GNAM MUST be silently discarded 💅

If the "MD" value is set to 0, the MN-HA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. Same energy as before: no MN-HA AE, too many MN-HA AEs, or a bad Authenticator means the MN MUST silently discard the GNAM. If the MN accepted the message, it MAY also process it based on the notification event 🌈

In the co-located CoA case, if the MN receives this message, the MN-HA AE MUST be checked, and the MN MUST check the Authenticator value in the Extension. If no MN-HA AE is found, more than one is found, or the Authenticator is invalid, the MN MUST silently discard the Notification Acknowledgement message 💀

4.6. Foreign Agent Consideration 🌸

The FA may initiate a GNM to the MN or the HA. It also relays GNMs and GNAMs between the MN and its HA, but only as long as there's an active binding for the MN at the FA 🧚

4.6.1. Receiving Generic Notification Messages 💖

When the FA receives a GNM, the "MD" value tells it what's going on. A value of 0 means the HA is asking the FA to relay the message to the MN. A value of 1 means the FA itself is the target of the notification. A value of 2 means the MN is asking the FA to relay the message to the HA. A value of 3 means the notification came from the MN to the FA 🎀

If the "MD" value is set to 0, the FA MAY validate the FA-HA AE if one is present. If the FA-HA AE is invalid, then all extensions between the HA-MN AE and the HA-FA AE MUST be removed, and the FA SHOULD relay the GNM to the MN's home address as given in the Home Address field of the GNM. The MN will eventually validate the MN-HA AE to make sure everything it received is integrity protected 🔐 If the FA-HA AE is valid, the FA MUST relay the GNM to the MN's home address as given in the Home Address field of the GNM. The FA MUST NOT modify any of the fields from the fixed portion of the GNM through the MN-HA AE, or through any other authentication extension the HA supplied as an authorization-enabling extension for the MN 🙅‍♀️

On top of that, the FA MUST process and remove any extensions after the MN-HA AE. If the FA shares a mobility security association with the MN, the FA MAY append any of its own non-authentication extensions that are relevant to the MN. In that case, the FA MUST append the MN-FA AE after those non-authentication extensions 🧁

If the "MD" value is set to 1, the FA-HA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If there's no FA-HA AE, more than one FA-HA AE, or the Authenticator is invalid, the FA MUST reject the GNM and MAY send a GNAM to the HA with Code 68, including an Identification field computed under the rules in Section 7.1. The FA MUST do no further processing with that notification, though it SHOULD log the error as a security exception 🚨

The FA MUST check that the Identification field is correct, using the context selected by the SPI within the mandatory FA-HA AE. See Section 7.1 for how that's done. If it's incorrect, the FA MUST reject the GNM and MAY send a GNAM to the initiator with Code 69, including an Identification field computed under the rules in Section 7.1. The FA MUST do no further processing with that notification, though it SHOULD log the error as a security exception 😭

The FA MUST also check that the extensions in the Generic Notification Message are permitted for use with the GNM. If they aren't, the FA MUST silently discard the message. It MUST NOT do any further processing with that notification, though it SHOULD log the error 🙈

If the FA accepts the HA's GNM, it processes it according to the specific rules for the extensions it contains. The FA MAY then reply to the HA with a GNAM with Code 0, based on the "A" flag in the GNM ✨

In the FA-CoA case, when the "MD" value is set to 2 and the FA received this message, the MN-FA AE is present, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If there's no MN-FA AE, more than one MN-FA AE, or the Authenticator is invalid, the FA MUST silently discard the GNM. If the MN-FA is valid, the FA MUST relay the GNM to the HA's address as given in the Home Agent Address field of the GNM. The HA will eventually validate the MN-HA AE to make sure everything it received is integrity protected. The FA MUST NOT modify any of the fields from the fixed portion of the GNM through the MN-HA AE, or through any other authentication extension the MN supplied as an authorization-enabling extension for the HA 🦋

The FA MUST process and remove any extensions after the MN-HA AE, and it MAY append any of its own non-authentication extensions of relevance to the HA, if applicable. It MUST also append the FA-HA AE if the FA shares a mobility security association with the HA 💜

If the "MD" value is set to 3, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension, as described in Section 3.7.2.1 of [RFC5944]. If there's no MN-FA AE, more than one MN-FA AE, or the Authenticator is invalid, the FA MUST reject the GNM and MAY send a GNAM to the MN with Code 67, including an Identification field computed under the rules in Section 7.1. The FA MUST do no further processing with that notification, though it SHOULD log the error as a security exception 🚨

The FA MUST check that the Identification field is correct, using the context selected by the SPI within the mandatory MN-FA AE. See Section 7.1 for how that's done. If it's incorrect, the FA MUST reject the GNM and MAY send a GNAM to the initiator with Code 69, including an Identification field computed under the rules in Section 7.1. The FA MUST do no further processing with that notification, though it SHOULD log the error as a security exception 😭

If the FA accepts the MN's GNM, it processes it according to the specific rules for the extensions it contains. The FA MAY then reply to the MN with a GNAM with Code 0, based on the "A" flag in the GNM 🌈

4.6.2. Sending Generic Notification Acknowledgement Messages

okay so the FA might need to relay a GNAM between the MN and the HA, or send one back as a reply to a GNM that was sent to it 💅 either way, the GNAM is set up like this.

The source address is the FA address, and the destination address is the HA's or MN's home address 🎀

The Code field of the GNAM gets picked by following the rules in Section 4.2. When replying to an accepted notification, an FA SHOULD respond with Code 0 ✨

The FA might reject a notification by sending back a GNAM with Code value 65 (administratively prohibited), which could be for a bunch of reasons 🙈 or 64 (reason unspecified), or 66 (insufficient resources).

If the FA is relaying this message to only the HA, the FA MUST NOT modify any of the fields starting at the fixed portion of the GNAM and running through the MN-HA AE, or any other authentication extension the MN supplied as an authorization-enabling extension for the MN 🔒 Furthermore, the foreign agent MUST process and remove any extensions that come after the MN-HA AE. If the FA shares a mobility security association with the HA, the FA MAY append any of its own non-authentication extensions that are relevant to the HA. In that case, the FA MUST append the FA-HA AE after those non-authentication extensions 🦋

If the notification message is from the HA to the FA, then the MD value is set to 5, and the ordering of the extensions is: any non-authentication Extensions intended for the FA, followed by the FA-HA AE defined in Section 3.5.4 of [RFC5944] 💜

If the notification message is from the MN to the FA, then the MD value is set to 4, and the ordering of the extensions is: any non-authentication Extensions intended for the FA, followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944] 🌸

4.6.3. Sending Generic Notification Messages

if the FA is starting a notification to the MN using the GNM, it MAY also notify the HA 🧚

In the message to the MN, the source address is the FA address, the destination address is the MN's address, the MD value is set to 4, and the ordering of the extensions is: the notification extension, then any non-authentication extensions intended for the MN, then the MN-FA AE defined in Section 3.5.3 of [RFC5944]. Computing the Authentication Extension Values works the same way as in Section 3.5.1 of [RFC5944], except the payload is the notification instead of the registration 💖

In the message to the HA, the source address is the FA's address, and the destination address is the HA's address (the MD value is set to 5). The ordering of the extensions is: the notification extension, then any non-authentication Extensions intended for the HA, then the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Value is done the same way as described in Section 3.5.1 of [RFC5944], except that the payload is the notification instead of the registration 🔥

4.6.4. Receiving Generic Notification Acknowledgement Messages

for an FA-CoA, if the FA receives this message and the MD value is set to 2, it means the notification acknowledgement message is from the MN to the HA. If the MD value is set to 3, the message is from the MN to the FA. Otherwise, it came from the HA 👑

If the MD value is set to 1, the FA-HA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the Notification Acknowledgement message. If the FA accepted this message, the FA MAY also process it based on the notification event 🫶

If the MD value is set to 3, and the MN-FA AE is present, the AE MUST be checked, and the FA MUST check the Authenticator value in the extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNAM. If the FA accepted this message, the FA MAY also process it based on the notification event ⭐

For an FA-CoA, and if the MD value is set to 2, and if the FA received this message, and if the MN-FA AE is present, the MN-FA AE MUST be checked, and the FA MUST check the Authenticator value in the Extension. If no MN-FA AE is found, or if more than one MN-FA AE is found, or if the Authenticator is invalid, the FA MUST silently discard the GNAM. If the FA accepted the MN's GNAM, it MUST relay this message to the HA. The FA MUST NOT modify any of the fields starting at the fixed portion of the GNAM and running through the MN-HA AE, or any other authentication extension the HA supplied as an authorization-enabling extension for the MN. Furthermore, the FA MUST process and remove any extensions following the MN-HA AE, and MAY append any of its own non-authentication extensions of relevance to the HA, if applicable. Also, it MUST append the FA-HA AE, if the FA shares a mobility security association with the HA 🌈

4.7. Home Agent Consideration

the HA MAY initiate a GNM to both the mobile node and the FA, and it also MAY receive a GNAM from both the FA and the MN. The HA also MAY receive a GNM from the FA, but only when there is a binding for an MN. If the HA receives a GNM from an FA and there is no corresponding MN registration, the HA SHOULD drop the GNM 🙅‍♀️

4.7.1. Sending Generic Notification Messages

for an FA-CoA, the HA may either send a GNM to notify the FA, or have the FA relay the GNM to the MN if the MN needs to be notified 🍓

If the message is from the HA to the FA, the source address is the HA's address, and the destination address is the FA's address.

If the FA is working only as a relay agent, the MD value is set to 0, and the ordering of the extensions is: the notification extension, then any non-authentication extension expected to be used by the MN, then the MN-HA AE defined in Section 3.5.2 of [RFC5944], then any non-authentication extensions intended for the FA, then the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Value is done the same way as in Section 3.5.1 of [RFC5944] 💅

If the FA is the target of this notification message, then the MD value is set to 1, and the ordering of the extensions is: the notification extension, then any non-authentication Extensions intended for the FA, then the FA-HA AE defined in Section 3.5.4 of [RFC5944]. Computing the Authentication Extension Values is done the same way as in Section 3.5.1 of [RFC5944] ✨

For a co-located CoA, the HA MAY send a notification message directly to the MN if it needs to be notified. The MD value is set to 0, and the ordering of the extensions is: the notification extension, then any non-authentication extension expected to be used by the MN, then the MN-HA AE defined in Section 3.5.2 of [RFC5944] 🦋

4.7.2. Receiving Generic Notification Acknowledgement Messages

for an FA-CoA, if the HA receives this message and the MD value is set to 2, it means the GNAM came from the MN 🌸

If the MD value is set to 5, and the HA accepted this message, the HA MAY also process it based on the notification event. The FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the extension. If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM 💀

If the MD value is set to 2, for an FA-CoA, and if the FA-HA AE is present, the FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. No matter what, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. If the HA accepted this message, the HA MAY also process it based on the notification event 🎀

If the MD value is set to 2, for a co-located CoA, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST silently discard the GNAM. If the HA accepted this message, the HA MAY also process it based on the notification event 🧚

4.7.3. Receiving Generic Notification Messages ✨

Okay bestie, the HA MAY receive a GNM sent from the FA 🦋 When the HA gets it, if the "MD" value is set to 5, then we know it came from the FA. The FA-HA AE MUST be checked, and the HA MUST check the Authenticator value in the extension 🔐 If no FA-HA AE is found, or if more than one FA-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 132, with an Identification field computed under the rules in Section 7.1. The HA MUST do no further processing with that notification, though it SHOULD log the error as a security exception 💀

The HA MUST check that the Identification field is correct, using the context selected by the SPI inside a mandatory authentication extension like MN-HA AE or FA-HA AE. Check Section 7.1 for how that works 🧠 If it's incorrect, the HA MUST reject the GNM and MAY send a GNAM to the initiator with Code 133, with an Identification field computed under the rules in Section 7.1. The HA MUST do no further processing with that notification, though it SHOULD log the error as a security exception. If the HA accepts the FA's GNM, it processes it based on the notification extension. Also, the HA MAY reply to the FA with a GNAM with Code 0 based on the "A" flag in the GNM ✨

If the "MD" value is set to 2, the message comes from the MN. In the case of FA-CoA, if FA-HA AE is present, it MUST be checked, and the HA MUST check the Authenticator value in the Extension. If more than one FA-HA AE Extension is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the FA with Code 132, with an Identification field computed under the rules in Section 7.1. The HA MUST do no further processing with that notification, though it SHOULD log the error as a security exception. Also, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the MN with Code 131, with an Identification field computed under the rules in Section 7.1. The HA MUST do no further processing with that notification, though it SHOULD log the error as a security exception. If the HA accepts the MN's GNM, it processes it based on the notification extension. Furthermore, the HA MAY reply to the MN with a GNAM back with Code 0 based on the "A" flag in the GNM 🌸

If the "MD" value is set to 2, and it's a co-located CoA, the MN-HA AE MUST be checked, and the HA MUST check the Authenticator value in the Extension. If no MN-HA AE is found, or if more than one MN-HA AE is found, or if the Authenticator is invalid, the HA MUST reject the GNM and MAY send a GNAM to the MN with Code 131, with an Identification field computed under the rules in Section 7.1. The HA MUST do no further processing with that notification, though it SHOULD log the error as a security exception. If the HA accepts the MN's GNM, it processes it based on the notification extension. Furthermore, the HA MAY reply to the MN with a GNAM with Code 0 based on the "A" flag in the GNM 🫶

The HA MUST also check that the extensions in the Generic Notification Message are permitted for use with the GNM. If not, the HA MUST silently discard the message. It MUST NOT do any further processing with that notification, though it SHOULD log the error 😭

4.7.4. Sending Generic Notification Acknowledgement Messages 💅

If the GNM came from the FA only, and the "A" flag is set in the GNM, then the HA MUST send a GNAM. Here's the vibe: the source address is the HA's address, the destination address is the FA's address, and the "MD" value is set to 1. The ordering of the extensions goes: any non-authentication Extensions meant for the FA, followed by the Foreign-Home Authentication extension defined in Section 3.5.4 of [RFC5944] 🧚

The Code field of the GNAM is chosen under the rules in Section 4.2. When replying to an accepted GNM, an MN SHOULD respond with Code 0 🍓

If the GNM came from the MN, and the "A" flag is set in the GNM, then the HA MUST send a GNAM. The source address is the HA's address, the destination address is the FA's address, and the "MD" value is set to 0. The ordering of the extensions is: any non-authentication extensions meant for the MN, followed by the MN-HA AE defined in Section 3.5.2 of [RFC5944], optionally followed by any non-authentication extensions meant for the FA, optionally followed by the MN-FA AE defined in Section 3.5.3 of [RFC5944] 🎀

5. Future Extensibility 🌈

This document defines the Generic Notification Message used with the Message String Extension [RFC4917].

However, it's totally possible to define new notification-related extensions for use with the Generic Notification Message, for cases where the notification has semantic content and is meant for the HA, FA, or MN, rather than for the user 👑

5.1. Examples of Possible Extensions 💖

One example of this, which would have been defined in this document if it hadn't already been defined as a separate message, is the Registration Revocation Message [RFC3543]. This is a message sent from the HA to the FA(s) or MN to notify the receiving node that a currently active registration is being revoked. The use case for this is clearly laid out in [RFC3543] ✨

Another example would be managed maintenance switch-over between HA instances, where an HA due to go down for maintenance could direct the MNs registered with it to re-register with another specified HA 🦋

Such a message could also be used for managed load balancing. There is currently no support for such forced switch-over in the Mobile IPv4 protocol 🙈

Yet another example is when the prefix set handled by an MIPv4 NEMO [RFC5177] HA changes. To ensure proper routing, the mobile router needs to be notified about the change so that its internal routing rules may be updated 🌈

One final example is home network changes that require host configuration changes, like a change of address for the DNS server or another network server. Again, this is a case where the HA would want to notify the MN of the change, so that service interruptions can be avoided 🫶

5.2. Extension Specification 🔥

To avoid making the MIPv4 Generic Notification Message a generic protocol extension mechanism, where new protocol mechanisms could be implemented without appropriate discussion and approval, any new extensions used with the Generic Notification Message must be registered with IANA. That registration is limited by the 'RFC Required' policy defined in [RFC5226] 🛡️

If additional extensions are specified for use with the Generic Notification Message, the practice exemplified in [RFC5944] and related specifications should be followed. Generally, it hasn't been necessary so far to provide versioning support within individual extensions. In a few cases, it has been necessary to define new extensions with new extension numbers where a generalization of a pre-existing extension was needed. With the current rate of extension number consumption, that seems to be an acceptable approach 🍓

If extensions are specified for use with the Generic Notification Message at some point that overlap with pre-existing notification messages, the authors of the specification should consider providing a method to flag which notification messages are supported, and which notification message usage is requested. This would work in a manner similar to the way tunneling method capabilities and usage requests are flagged in the Mobile IPv4 base specification [RFC5944] 🎀

Encoded in the extension number of Mobile IPv4 extensions is the notion of 'skippable' and 'not skippable' extensions; see Section 1.8 of [RFC5944]. This notion also applies when extensions are used with the Generic Notification Message. It is not required that a receiver understand a skippable extension, but a non-skippable extension needs to be handled according to Section 1.8 of [RFC5944] (i.e., the message must be silently discarded if the extension is not recognized). This document does not specify any change from the Mobile IPv4 base specification [RFC5944] in this respect 🧠

6. IANA Considerations 📋

This document defines two new messages: the Generic Notification Message described in Section 4.1, and the Generic Notification Acknowledgement Message described in Section 4.2. The message numbers for these two messages have been allocated from the same number space used by the Registration Request and Registration Reply messages in [RFC5944] 🔢

The Generic Notification Message may only carry extensions that are explicitly permitted for use with this message. Section 4.1 of this document defines 4 extensions that are permitted. IANA has added a column to the registry of Mobile IPv4 extensions, which indicates for each extension whether it is permitted for use with the Generic Notification Message. Approval of new extensions that are permitted for use with the Generic Notification Message requires that they be defined in an RFC according to the 'RFC Required' policy described in [RFC5226] 📚

The Generic Notification Acknowledgement Message, specified in Section 4.2, has a Code field. The number space for the Code field values is new and also specified in Section 4.2. The Code number space is structured according to whether the notification was successful, the HA denied the notification, the FA denied the notification, or the MN denied the notification, like this:

          0       Success Code
          64-69   Error Codes from the FA
          128-133 Error Codes from the HA
          192-197 Error Codes from the MN

Approval of new Code values requires expert review 🧐

7. Security Considerations 🚨

Okay this section is SERIOUS, bestie. Read every word 🙏

This specification operates with the security constraints and requirements of [RFC5944]. That means that when this message is transmitted between the MN and the HA, the MN-HA AE is REQUIRED. When this message is transmitted between the MN and the FA, the MN-FA AE is REQUIRED. When this message is transmitted between the FA and the HA, the FA-HA AE is REQUIRED. It extends the operations of the MN, HA, and FA defined in [RFC5944] to notify each other about some events. The GNM defined in this specification could carry information that modifies the mobility bindings. Therefore, the message MUST be integrity protected. Replay protection MUST also be guaranteed 🔐🔐

RFC 5944 provides replay protection only for Registration Requests sent by the MN. There is no mechanism for replay protection for messages initiated by an FA or HA. The 64-bit Identification field specified in this document (Sections 4.1 and 4.2) for the GNM is used to provide replay protection for the notification messages initiated by the FA or HA 🌈

7.1. Replay Protection for GNMs and GNAMs 🔐

okay so the Identification field is how the receiving node checks that a GNM was freshly made by the sender and not replayed by some attacker from an old notification 👀 no sneaky reruns allowed. There are two methods here: timestamps (REQUIRED) and "nonces" (OPTIONAL). Every sender and receiver MUST implement timestamp-based replay protection. These nodes MAY also implement nonce-based replay protection.

The style of replay protection between any two peer nodes among the MN, FA, and HA is part of the mobile security association 🫶. A sending node and its receiving node MUST agree on which method they're using. The meaning of the Identification field depends on the method, as the next subsections explain.

Whatever method is in use, the low-order 32 bits of the Identification field MUST be copied unchanged from the GNM to the GNAM ✨. The receiver uses those bits, plus the sender's source address, to match each GNAM with its reply. The receiver MUST verify that the low-order 32 bits of any GNAM Identification field are identical to the bits it sent in the GNM.

The Identification in a new GNM MUST NOT be the same as in an immediately preceding GNM. It SHOULD NOT repeat while the same security context is being used between the MN and the HA. no repeats, bestie 💅

7.1.1. Replay Protection Using Timestamps ⏰

the basic idea is super simple 💖. The node making the message stamps in the current time of day, and the node receiving it checks that the stamp is close enough to its own clock. Unless the security association between the nodes says otherwise, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. Obviously, the two nodes need their time-of-day clocks properly synchronized. As with any messages, the time synchronization messages may be protected against tampering by an authentication mechanism set by the security context between the two nodes.

In this document, timestamps are used, and the sender MUST set the Identification field to a 64-bit value formatted as specified by the Network Time Protocol (NTP) [RFC5905]. The low-order 32 bits of the NTP format represent fractional seconds ⏱️. but here's the tea ☕: when you use timestamps, the 64-bit Identification in a GNM from the sender MUST be greater than the one in any previous GNM, because the receiver uses this field as a sequence number too. Without that, a delayed duplicate of an earlier GNM could show up at the receiver (still within the clock sync the receiver allows) and get applied out of order, quietly messing up the sender's current status 😭.

Upon receiving a GNM with an authorization-enabling extension, the receiver MUST check the Identification field for validity. To be valid, the timestamp in the Identification field MUST be close enough to the receiver's time-of-day clock, and the timestamp MUST be greater than all previously accepted timestamps for the requesting sender. Time tolerances and re-synchronization details are specific to a particular mobility security association 🎀.

If the timestamp is valid, the receiver copies the entire Identification field into the GNAM and sends the GNAM back to the sender ✅. If the timestamp is not valid, the receiver copies only the low-order 32 bits into the GNAM and fills in the high-order 32 bits from its own time of day. In that latter case, the receiver MUST reject the notification by returning Code 69, 133, or 197 (notification Identification mismatch) in the GNAM 🙈.

Furthermore, before using the high-order bits for clock re-synchronization, the receiver MUST verify that the low-order 32 bits of the Identification in the GNAM are identical to those in the rejected GNM attempt. double-check, then resync 🧚

7.1.2. Replay Protection Using Nonces 🎲

the basic principle here is that node A includes a brand-new random number in every message to node B, and checks that node B returns that same number in its next message to node A 💜. Both messages use an authentication code to protect against alteration by an attacker. At the same time, node B can send its own nonces in all messages to node A (to be echoed back by node A), so it can also check that it's getting fresh messages. mutual fresh-check energy, iconic

The receiver may be expected to have resources for computing pseudo-random numbers that are useful as nonces, according to [RFC4086]. It inserts a new nonce as the high-order 32 bits of the Identification field in every GNAM. It copies the low-order 32 bits of the Identification field from the GNM into the low-order 32 bits of the Identification field in the GNAM. When the sender gets an authenticated GNAM from the receiver, it saves the high-order 32 bits of the Identification field to use as the high-order 32 bits of its next GNM 🌸.

The sender is responsible for generating the low-order 32 bits of the Identification field in each GNM. Ideally, it should make its own random nonces. However, it may use any expedient method, including duplicating the random value the receiver sent. The method is only the sender's concern, because the sender is the node that checks for valid values in the GNAM. The high-order and low-order 32 bits of the Identification chosen SHOULD both differ from their previous values. For each notification message, the receiver uses a new high-order value, and the sender uses a new low-order value 🦋.

If a GNM is rejected because of an invalid nonce, the GNAM always gives the sender a new nonce to use in the next message. So the nonce protocol is self-synchronizing 🔄 it fixes itself, periodt 🌈.

7.2. Non-Authentication Extensions Handling in the Foreign Agent 🛡️

when the FA is relaying a GNM between the MN and the HA, and the FA doesn't share a mobility security association with the MN or the HA, none of the non-authentication extensions between the MN and FA, or between FA and HA, are protected 🙃. In that case, all non-authentication extensions should be silently discarded 🤫.

8. Acknowledgements 🫶

the authors really appreciate Ahmad Muhanna for his detailed review and his many contributions to the text 💖. The author also wants to thank Kent Leung, Peng Yang, Peter McCann, et al., for helping develop this document. Thanks to Alexey Melnikov, Sean Turner, Ralph Droms, Charles E. Perkins, Russ Housley, Magnus Westerlund, Lars Eggert, Dan Romascanu, Tim Polk, Amanda Baber, Sebastian Thalanany, and Joseph Salowey for their discussion and comments 👑. And thanks to Jari Arkko for help at every step of this document's development 🎀.

9. References 📚

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3543]  Glass, S. and M. Chandra, "Registration Revocation in
           Mobile IPv4", RFC 3543, August 2003.

[RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
           Requirements for Security", BCP 106, RFC 4086, June 2005.

[RFC4917]  Sastry, V., Leung, K., and A. Patel, "Mobile IPv4 Message
           String Extension", RFC 4917, June 2007.

[RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
           Time Protocol Version 4: Protocol and Algorithms
           Specification", RFC 5905, June 2010.

[RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
           RFC 5944, November 2010.

9.2. Informative References

[RFC5177]  Leung, K., Dommety, G., Narayanan, V., and A. Petrescu,
           "Network Mobility (NEMO) Extensions for Mobile IPv4",
           RFC 5177, April 2008.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

Authors' Addresses 🎀

Hui Deng
China Mobile
53A, Xibianmennei Ave.,
Xuanwu District,
Beijing  100053
China

EMail: denghui02@gmail.com


Henrik Levkowetz
Netnod
Franzengatan 5
S-104 25, Stockholm
SWEDEN

EMail: henrik@levkowetz.com


Vijay Devarapalli
Vasona Networks
2900 Lakeside Drive
Santa Clara, CA  95054
USA

EMail: dvijay@gmail.com


Sri Gundavelli
Cisco
170 W.Tasman Drive
San Jose, CA  95134
USA

EMail: sgundave@cisco.com


Brian Haley
Hewlett-Packard Company
165 Dascomb Road
Andover, MA  01810
USA

EMail: brian.haley@hp.com

that's the whole spec, bestie 💜✨ ily for reading all of it 🫶💅

📦 where this page comes from

ietf: rfc6098 2012-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms