RFC 7077

Update Notifications for Proxy Mobile IPv6

📅 published November 2013, from ietf

Update Notifications for Proxy Mobile IPv6 ✨

Okay bestie, let's start with the ID card 🪪 This is RFC 7077, and it's called Update Notifications for Proxy Mobile IPv6. The authors are S. Krishnan (Ericsson), S. Gundavelli (Cisco), M. Liebsch (NEC), H. Yokota (KDDI), and J. Korhonen (Broadcom). It's a Standards Track document, dated November 2013, with ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so no older RFC gets replaced or patched here 💅

Abstract

Okay so this doc is all about giving the local mobility anchor (LMA) in a Proxy Mobile IPv6 domain a way to send asynchronous notifications to the mobile access gateway (MAG) about changes to a mobility session 📨 These Update Notification messages travel in a brand new Mobility Header message type that was made for exactly 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 has the community's consensus behind it 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741.

You can find the current status, any errata, and the feedback info at http://www.rfc-editor.org/info/rfc7077 ✨

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 doc 📜 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💜

   1. Introduction ....................................................3
   2. Conventions and Terminology .....................................4
      2.1. Conventions ................................................4
      2.2. Terminology ................................................4
   3. Notification Message - Usage Examples ...........................4
   4. Message Formats .................................................5
      4.1. Update Notification (UPN) ..................................5
      4.2. Update Notification Acknowledgement (UPA) ..................7
   5. LMA Considerations ..............................................9
      5.1. Constructing the Update Notification Message ..............10
      5.2. Receiving the Update Notification Acknowledgement
           Message ...................................................11
   6. MAG Considerations .............................................12
      6.1. Receiving the Update Notification Message .................12
      6.2. Constructing the Update Notification Acknowledgement
           Message ...................................................15
   7. Protocol Configuration Variables ...............................16
   8. Security Considerations ........................................16
   9. Acknowledgements ...............................................17
   10. IANA Considerations ...........................................17
   11. References ....................................................19
      11.1. Normative References .....................................19
      11.2. Informative References ...................................19

1. Introduction 🧚

Sometimes the LMA needs to send asynchronous notification messages to the MAG during a mobility session 💖 Stuff like changes to session parameters and policy parameters can trigger this. Here, "Asynchronous messages" just means messages that aren't in sync with the Proxy Binding Update and Proxy Binding Acknowledgement messages from the base Proxy Mobile IPv6 spec [RFC5213]. And the base spec has no way for the LMA to send unsolicited Update Notification messages to the MAG, which is the gap we're filling 🙈

Quick refresher on Proxy Mobile IPv6 [RFC5213] 🌈 It's a network-based mobility management protocol, which means it gives IP mobility support to a mobile node without the mobile node having to take part in any mobility signaling at all. There are two mobility management entities, the LMA and the MAG, and together they look after IP mobility for a mobile node in a Proxy Mobile IPv6 domain. The MAG kicks things off by sending a Proxy Binding Update, and the LMA acknowledges it with a Proxy Binding Acknowledgement. Once the session is up, though, the LMA has no mechanism to tell the MAG about changes to the session or any related parameters. There are asynchronous signaling messages it can send, like the Proxy Mobile IPv6 Heartbeat message [RFC5847] or the Binding Revocation message [RFC5846], but those are built for very specific purposes and aren't enough for a real notification framework 🥺

One scenario that needs this is when the LMA wants the MAG to re-register the mobility session for a mobile node 🔁 You could fake a similar effect with a short session lifetime, but in lots of networks that causes an unacceptable (and mostly unnecessary) jump in signaling load and overhead 😭 Way better: demand-based signaling from the LMA to one or more MAGs 🔥 Another example is when a QoS policy [PMIPv6-QoS], an IP flow mobility policy [PMIPv6-FLOW-MOB], or an IPv4 traffic offload policy [RFC6909] changes for a mobility session. Then the LMA wants the MAG to re-register the session so the policies tied to that mobile node's session get updated ✨

This document defines a new Mobility Header message that lets the LMA send notification messages to the MAG, plus a matching Mobility Header message so the MAG can acknowledge the notification 🦋 The notification has two jobs: (1) letting the LMA tell the MAG about updated session parameters, and (2) letting the LMA ask the MAG to renegotiate the session parameters 👑

2. Conventions and Terminology 📚

2.1. Conventions

Okay so here are the BCP 14 key words 🔑 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]. 💅

2.2. Terminology

All the mobility-related terms in this doc mean what they mean in the base Proxy Mobile IPv6 specifications [RFC5213] and [RFC5844] 🌸 No new definitions, no drama 🙌

3. Notification Message - Usage Examples 🎀

Let's look at two use cases. Lowkey the diagrams explain it better than I can 🥹

Use Case 1: The LMA wants the MAG to re-register a specific mobility session 🔁

   MN     MAG       LMA
   |------>|        |    1.  Mobile Node Attach
   |       |------->|    2.  Proxy Binding Update
   |       |<-------|    3.  Proxy Binding Acknowledgement
   |       |========|    4.  Tunnel/Route Setup
   |       |        |
   |       |<-------|    5.  Update Notification (FORCE-REREGISTRATION)
   |       |------->|    6.  Update Notification Acknowledgement
   |       |        |
   |       |------->|    7.  Proxy Binding Update
   |       |<-------|    8.  Proxy Binding Acknowledgement
   |       |        |

            Figure 1: Update Notification: FORCE-REREGISTRATION

Use Case 2: The LMA wants to tell the MAG about updated session parameters, like an updated QoS profile or an updated IPv4 offload policy 🍓

   MN     MAG     LMA
   |------>|        |    1.  Mobile Node Attach
   |       |------->|    2.  Proxy Binding Update
   |       |<-------|    3.  Proxy Binding Acknowledgement
   |       |========|    4.  Tunnel/Route Setup
   |       |        |
   |       |<-------|    5.  Update Notification
   |       |        |           (UPDATE-SESSION-PARAMETERS)
   |       |------->|    6.  Update Notification Acknowledgement
   |       +        |    7.  MAG applies the new policy option
   |       |        |

         Figure 2: Update Notification: UPDATE-SESSION-PARAMETERS

4. Message Formats ✨

4.1. Update Notification (UPN) 🔔

Okay bestie, the Update Notification is a Mobility Header message with an MH Type value of 19 ✨ The local mobility anchor sends it to the mobile access gateway to say "hey, some parameters for this mobility session just changed!" 💌

   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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |           Sequence #          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Notification Reason        |A|D|          Reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Update Notification Message

Sequence Number 🔢

This 16-bit unsigned integer is how the local mobility anchor matches an Update Notification Acknowledgement with its Update Notification 🎯 The Sequence Number could be a random number, and it can be managed under the same variable used in Proxy Mobile IPv6 signaling messages [RFC5213]. Implementations MUST ensure that there is no collision between the Sequence Numbers of all outstanding Update Notification messages at any time 🙈

Notification Reason 📣

This 16-bit unsigned integer holds the Notification Reason code, which tells the mobile access gateway why the local mobility anchor sent the Update Notification 💅 The field has no internal structure and MUST be treated as an enumeration. A reason code can point to a vendor-specific reason if the meaning of the message is based on the attached vendor-specific options rather than only on the code. Those attached options can be deployment specific and are not specified in this document. These are the Notification Reason values defined right now:

(0) - Reserved: this value is currently reserved and cannot be used.
(1) - FORCE-REREGISTRATION: a request to re-register the session by sending a Proxy Binding Update for the mobility session.
(2) - UPDATE-SESSION-PARAMETERS: a request to apply the updated session parameters obtained from the message on the mobility session.
(3) - VENDOR-SPECIFIC-REASON: this one is for vendor-specific use. The processing rules are based on the Vendor-Specific Mobility option(s) [RFC5094] present in the message.
(4) - ANI-PARAMS-REQUESTED: a request to send the currently known Access Network Identifier (ANI) [RFC6757] parameters for the mobility session.
(255) - Reserved: this value is currently reserved and cannot be used.

Acknowledgement Requested Flag ((A) Flag) 🙋‍♀️

When this flag is set to a value of (1), the local mobility anchor is asking the mobile access gateway to send an Update Notification Acknowledgement message. When it is set to (0), the local mobility anchor is not asking for any Update Notification Acknowledgement messages 💌

Retransmit Flag ((D) Flag) 🔁

When this flag is set to a value of (1), the message is a retransmission and has the same Sequence Number and other message contents as the previously sent message. The (D) flag gets set on retransmitted request messages so the receiver can reliably spot duplicate requests 🕵️‍♀️ It's set when originating requests that haven't been acknowledged yet, as a hint that a duplicate might be due to a retransmission. This flag MUST be cleared when sending a request for the first time for a given Sequence Number; otherwise, the sender MUST set this flag 🎀

Reserved 🫥

This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.

Mobility Options 🧩

This variable-length field is sized so the complete Mobility Header is an integer multiple of 8 octets long, and the Pad1 and PadN options [RFC6275] can be used for padding 🧚 It holds zero or more TLV-encoded mobility options. Any of the Mobility Header options can go here, including Vendor-Specific Mobility options [RFC5094]. The receiver MUST ignore and skip any options it does not understand. The mobile access gateway uses these mobility options to figure out which specific binding the Update Notification message is for ✨

4.2. Update Notification Acknowledgement (UPA) 💜

The Update Notification Acknowledgement is a Mobility Header message with an MH Type value of 20 🦋 The mobile access gateway sends it to confirm it got an Update Notification with the (A) flag set, and to report the status after processing that message.

   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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |           Sequence #          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Status Code |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Update Notification Acknowledgement Message

Sequence Number 🔢

This 16-bit unsigned integer is copied from the Update Notification message and is used to match the Update Notification Acknowledgement with the Update Notification message 🫶

Status Code 🚦

This 8-bit unsigned integer gives the status code and the result of processing the Update Notification message. Codes between 0 and 127 mean the Update Notification was processed successfully, and codes between 128 and 255 mean an error happened during processing 😭 These are the status code values defined right now:

(0) - SUCCESS: the mobile access gateway successfully processed the received Update Notification message.
(128) - FAILED-TO-UPDATE-SESSION-PARAMETERS: the mobile access gateway was not able to apply the session parameters the local mobility anchor sent in the Update Notification message.
(129) - MISSING-VENDOR-SPECIFIC-OPTION: the received Update Notification message doesn't have the required Vendor-Specific Mobility option(s) needed to handle the message.

Reserved 🫥

This field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver.

Mobility Options 🧩

This variable-length field is sized so the complete Mobility Header is an integer multiple of 8 octets long, and the Pad1 and PadN options [RFC6275] can be used for padding 🌸 It holds zero or more TLV-encoded mobility options. Any of the Mobility Header options can go here, including Vendor-Specific Mobility options [RFC5094]. The receiver MUST ignore and skip any options it does not understand. The mobile access gateway uses these options to identify the specific binding for which the Update Notification Acknowledgement message is sent 💅

5. LMA Considerations 👑

The local mobility anchor sends the Update Notification message in response to a condition specified in the Notification Reason field. The Notification Reason field in the Update Notification message MUST be set to a specific value that identifies why the Update Notification message is being sent 🎯 Depending on the chosen value, the Notification Reason may require a specific action from the mobile access gateway, such as re-registering a mobility session.
The Update Notification message MUST include either the Mobile Node Identifier option [RFC4283] or the Mobile Node Group Identifier option [RFC6602].
- If the Mobile Node Identifier option is present, the Update Notification message is sent for that specific mobility session.
- If the Mobile Node Group Identifier option is present, the Update Notification message is sent for the set of mobility sessions identified by the Group Identifier. The Group Identifier is negotiated as part of the initial Proxy Mobile IPv6 signaling. If the Group Identifier is not negotiated in the initial Proxy Mobile IPv6 signaling, a value of (1) for the Group Identifier can always be used. The Group Identifier value of (1) identifies all the mobility sessions established between that local mobility anchor and the mobile access gateway 🌈
The Update Notification message MAY contain a modified session parameter in the form of a mobility option (for example, an IPv4 traffic offload option or a QoS option), so the mobile access gateway can apply them to the identified mobility session 🧚‍♀️

5.1. Constructing the Update Notification Message 🎀

okay so bestie, the LMA is the one building the Update Notification before it goes to the MAG, and there's a checklist for it 📋✨

The (A) flag is basically the "ack me back plz" switch 🔔. It MUST be set to (1) if the LMA wants an Acknowledgement plus the result of processing from the MAG, and it MUST be set to (0) otherwise. BUT if the Notification Reason is (1) "FORCE-REREGISTRATION" or (4) "ANI-PARAMS-REQUESTED", it's RECOMMENDED to keep the (A) flag at (0) 💅. For general, just-FYI notifications, the LMA may skip asking for an ack, which is totally valid 🦋
The Sequence Number field MUST start at a random number and go up monotonically for each new message 🔢. When it hits the max, it should wrap back around to 0 🔄. And if you're retransmitting a message you already sent, the Sequence Number does NOT change 🙅‍♀️
IPv4 transport is its own whole vibe 🌸. The source address in the IPv4 header MUST be the LMA's IPv4 address (IPv4-LMAA), and the destination MUST be the mobile access gateway's IPv4-Proxy-CoA (Care-of Address). The Mobility Header (without the IPv6 header) with the Update Notification gets wrapped in a UDP header with destination port 5436 [RFC5844]. If you're protecting signaling with IPsec Encapsulating Security Payload (ESP) [RFC4303], the packet is processed using transport mode ESP 🔐

Here's how the IPv4 packet stacks up 👇

IPv4 header (src=IPv4-LMAA, dst=IPv4-Proxy-CoA)
  ESP header (in transport mode)
    UDP header (sport=5436, dport=5436)
      Mobility Header (Update Notification)
        (one or more Mobility Header options)

IPv6 transport has its own rules too 💜. The source address in the IPv6 header MUST be the LMA's IPv6 address (LMAA), and the destination address MUST be the Proxy-CoA of the mobile access gateway. Here the Mobility Header is part of the IPv6 headers itself 🧚

And the IPv6 version of the packet looks like this ✨

IPv6 header (src=LMAA, dst=Proxy-CoA)
  Mobility Header (Update Notification)
  ESP header (in transport mode)
    (one or more Mobility Header options)

5.2. Receiving the Update Notification Acknowledgement Message 💌

this is the part where the LMA waits for the ack and handles whatever comes back, and honestly it's giving reliability engineering 😭

If the LMA doesn't get an Update Notification Acknowledgement for an Update Notification that had the (A) flag set, the LMA MUST retransmit it 🔁. Some things to keep in mind:
- When retransmitting, the Sequence Number and everything else in the message MUST stay exactly the same as the original 🧸. The (D) flag MUST be set to (1) 🚩.
- There MUST be a minimum gap of MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY (Section 7) between two retransmits, and the default for that is 1000 milliseconds ⏳.
- The message MUST be retransmitted up to the number of times set by MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT (Section 7), which defaults to (1) 🔢. If there's still no ack once the retransmit count hits that value, the message MUST be discarded, and the event SHOULD be logged 📝
If the LMA gets a Binding Error with the Status field set to 2, as described in [RFC6275], that means the mobile access gateway doesn't support Update Notification messages 🙅‍♀️. So the LMA MUST NOT send any more Update Notification messages to that MAG unless an administrator steps in 🛑
When the LMA receives an Update Notification Acknowledgement, it MUST verify the Mobility Header as described in Section 9.2 of [RFC6275] 🔍. If the packet gets dropped because any Mobility Header test check fails, the LMA MUST follow the processing rules in Section 9.2 of [RFC6275] too 💅
Once the ack arrives, the LMA MUST check that it's protected by the same security association used for the other signaling between those two peers 🔐. For example, if the Proxy Binding Update and Proxy Binding Acknowledgement are protected with an IPsec security association [RFC4301], then the Update Notification Acknowledgement MUST have IPsec protection with that currently established security association 🫶
If the LMA gets an Update Notification Acknowledgement with a failure status of 128 or greater, it SHOULD log an error ❌
If the Sequence Number in a received Update Notification Acknowledgement doesn't match any Update Notification the LMA sent, the message MUST be discarded, and the message should be logged 🕵️‍♀️
Last one, and it's a fun twist 🌈: if the LMA gets an Update Notification Acknowledgement for an Update Notification that did NOT have the (A) flag set, the LMA MUST process that message the same way it would handle a response to an Update Notification with the (A) flag set 👑

6. MAG Considerations ✨

6.1. Receiving the Update Notification Message 💌

okay so when a mobile access gateway gets an Update Notification message, it MUST verify the Mobility Header as described in Section 9.2. of [RFC6275]. If the packet gets dropped because any of the Mobility Header test checks fail, the mobile access gateway MUST follow the processing rules in Section 9.2 of [RFC6275]. 🔍

Upon receiving the Update Notification message, the mobile access gateway MUST verify that the packet is protected by the security association that's already protecting the other signaling messages between those two peers. For example, if the Proxy Binding Update and Proxy Binding Acknowledgement messages are protected with an IPsec security association, then the Update Notification message MUST have IPsec protection with the currently established IPsec security association that's protecting the other Proxy Mobile IPv6 signaling messages. 🔐
If the Update Notification message is a retransmission of one that was already received (you can tell by the Sequence Number), the mobile access gateway MUST NOT handle it as a new request. The (D) flag is the sign of a retransmitted request, like when messages got lost or the local mobility anchor hasn't seen the update actions happen. If the mobile access gateway never saw the (possibly lost) initial request, it MUST treat the received Update Notification message (with the (D) flag set) as an initial request and keep processing from there. If it detects a retransmission from the (D) flag and the Sequence Number, it SHOULD redo the requested update action, for example when the Acknowledgement Requested ((A)) flag is not set. And the mobile access gateway MUST always respond to a retransmitted request if the (A) flag is set. 🔁
Upon accepting the Update Notification message, the mobile access gateway MUST process it and perform the actions based on the Notification Reason. 🎬
- If the (A) flag is set to a value of (1), the mobile access gateway MUST send an Update Notification Acknowledgement message with the status code field set based on the result of processing the Update Notification message.
- If the Notification Reason is set to a value of (1) "FORCE-REREGISTRATION", the mobile access gateway MUST send a Proxy Binding Update message to the local mobility anchor and get the updated session parameters for that mobility session. 🔄
- If the Notification Reason is set to a value of (2) "UPDATE-SESSION-PARAMETERS", the mobile access gateway MUST apply the session parameters obtained from the Update Notification message in the form of mobility options. However, if the mobile access gateway can't apply the received session parameters, it MUST apply the following considerations:
  - If the (A) flag in the received Update Notification message is set to a value of (0), the mobile access gateway MUST drop the received Update Notification message and log the error. 🙈
  - If the (A) flag in the received Update Notification message is set to a value of (1), the mobile access gateway MUST send an Update Notification Acknowledgement message with a status code value of 128 (FAILED-TO-UPDATE-SESSION-PARAMETERS).
- If the Notification Reason is set to a value of (3) "VENDOR-SPECIFIC-REASON", the mobile access gateway MUST apply the considerations related to handling the Vendor-Specific Mobility option [RFC5094] carried in the Update Notification message. However, if there's no Vendor-Specific Mobility option in the message, the mobile access gateway MUST apply the following considerations:
  - If the (A) flag in the received Update Notification message is set to a value of (0), the mobile access gateway MUST drop the received Update Notification message and log the error.
  - If the (A) flag in the received Update Notification message is set to a value of (1), the mobile access gateway MUST send an Update Notification Acknowledgement message with a status code value of 129 (MISSING-VENDOR-SPECIFIC-OPTION). 🧩
- If the Notification Reason is set to a value of (4) "ANI-PARAMS-REQUESTED", the mobile access gateway MUST send a Proxy Binding Update message to the local mobility anchor with the Access Network Identifier option [RFC6757]. The Access Network Identifier option MUST reflect the current access network parameters for that mobility session as the mobile access gateway knows them at the moment it sends the Proxy Binding Update message. 📡
- For other Notification Reason values that aren't reserved by this document, the processing the mobile access gateway needs to do is out of scope for this document. It'll be specified for each Notification Reason defined by other documents. 📚

6.2. Constructing the Update Notification Acknowledgement Message 🎀

when the mobile access gateway sends an Update Notification Acknowledgement message to the local mobility anchor, it needs to build the message like this:

The Sequence Number MUST be the same as the Sequence Number from the received Update Notification message. 🔢
The Status field of the Update Notification message MUST be set to a value that reflects the outcome of processing the Update Notification request. A value of 0 (SUCCESS) means the Update Notification message was handled successfully. ✅
The Update Notification Acknowledgement message MUST contain either the Mobile Node Identifier option or the Mobile Node Group Identifier option, copied from the Update Notification message. The mobile access gateway MAY also include other Mobility Header options. 🫶
The source address in the IP header of the Update Notification Acknowledgement message MUST be set to the destination IP address of the received Update Notification message. 📮
The destination address in the IP header of the Update Notification Acknowledgement message MUST be set to the source address of the received Update Notification message. 📬
If IPsec ESP is used to protect signaling, the packet is processed using transport mode ESP. 🔒

Here's the format of the Update Notification Acknowledgement message sent over IPv4 and protected using ESP:

IPv4 header (src=IPv4-Proxy-CoA, dst=IPv4-LMAA)
  ESP header (in transport mode)
    UDP header (sport=5436, dport=5436)
      Mobility Header (Update Notification Acknowledgement)
        (one or more Mobility Header options)

And here's the format of the Update Notification Acknowledgement message sent over IPv6 and protected using ESP:

IPv6 header (src=Proxy-CoA, dst=LMAA)
  Mobility Header (Update Notification Acknowledgement)
  ESP header (in transport mode)
    (one or more Mobility Header options)

7. Protocol Configuration Variables ⚙️

this spec defines the following configuration variables that control the Update Notification feature. ✨

The mobility entities, the local mobility anchor, and the mobile access gateway have to let system management configure these variables. The configured values for these protocol variables have to survive server reboots and service restarts. 💾

MAX_UPDATE_NOTIFICATION_RETRANSMIT_COUNT

This variable is the maximum number of times a local mobility anchor can retransmit an Update Notification message before it gets an Update Notification Acknowledgement message. The default is 1. The suggested range for this variable is between 0 and 5. 🔁

MIN_DELAY_BETWEEN_UPDATE_NOTIFICATION_REPLAY

This variable is the minimum delay in seconds before an Update Notification message gets retransmitted. The default for this parameter is 1000 milliseconds. The suggested range for this variable is between 500 and 5000 milliseconds. ⏱️

8. Security Considerations 🔐

ok this is the serious part, bestie. 😭 The Update Notification protocol in this specification is for use between a local mobility anchor and a mobile access gateway. This specification defines two new Mobility Header messages: Update Notification messages and Update Notification Acknowledgement messages. These Mobility Header messages have to be protected with the same security mechanism that protects the Proxy Mobile IPv6 signaling messages exchanged between a given local mobility anchor and mobile access gateway. 🛡️

If IPsec is used, the IPsec security association that protects the Proxy Binding Update and Proxy Binding Acknowledgement also needs to protect the Update Notification and Update Notification Acknowledgement messages. A Proxy Mobile IPv6 implementation and the IPsec layer are typically able to talk to each other through an implementation-specific interface, for example to exchange configuration and notification information. 🤝

The traffic selectors tied to the Security Policy Database (SPD) entry that protects Proxy Binding Update and Proxy Binding Acknowledgement messages (Section 4.2 of [RFC5213]) have to be extended to include the Mobility Header Type values 19 and 20. Those values were allocated for Update Notification and Update Notification Acknowledgement messages, respectively. Also, any time the IPsec security association between the mobile access gateway and the local mobility anchor gets rekeyed, the newly established IPsec security association will protect the Update Notification and Update Notification Acknowledgement messages. 🔑

9. Acknowledgements 💖

the authors want to thank Basavaraj Patil, Rajeev Koodli, Lionel Morand, Itsuma Tanaka, Rajesh Pazhyannur, Carlos Jesus Bernardos Cano, John Kaippallimalil, Brian Haberman, and other members of the NETEXT working group for all the comments and discussions on the document. 🫶

The authors also want to thank Barry Leiba, Robert Sparks, Carlos Pignataro, Benoit Claise, Stephen Farrell, and Jari Arkko for their inputs to the document as part of the IESG review process. 🌸

10. IANA Considerations 🎀

okay bestie, IANA is the org that keeps the big registries of protocol numbers, so this section is basically the to-do list for them ✨ 💅

This spec makes a brand new Mobility Header message type called Update Notification. It's described in Section 4.1, and it got the type value 19 from the "Mobility Header Types - for the MH Type field in the Mobility Header" registry at <http://www.iana.org/assignments/mobility-parameters> 🦋
It also makes another new Mobility Header message type called Update Notification Acknowledgement. That one's in Section 4.2, and it got the type value 20 from that same "Mobility Header Types - for the MH Type field in the Mobility Header" registry at <http://www.iana.org/assignments/mobility-parameters> 💜
Next, a brand new registry for Notification Reasons, called the "Update Notification Reasons Registry" 🌈. It lives under the "Mobile IPv6 Parameters" registry at <http://www.iana.org/assignments/mobility-parameters>. The Notification Reason is a field in the Update Notification message (Section 4.1), and IANA needs to manage its number space under the "Update Notification Reason Registry". This spec reserves these type values, and the allocation policy is "Specification Required" [RFC5226] 📜

+=====+===========================+====================+
|Value|       Description         |     Reference      |
+=====+===========================+====================+
| 0   | Reserved                  |     [RFC7077]      |
+=====+================================================+
| 1   | FORCE-REREGISTRATION      |     [RFC7077]      |
+=====+================================================+
| 2   | UPDATE-SESSION-PARAMETERS |     [RFC7077]      |
+=====+================================================+
| 3   | VENDOR-SPECIFIC-REASON    |     [RFC7077]      |
+=====+================================================+
| 4   | ANI-PARAMS-REQUESTED      |     [RFC7077]      |
+=====+================================================+
|255  | Reserved                  |     [RFC7077]      |
+=====+================================================+

And one more new registry for Status, called the "Update Notification Acknowledgement Status Registry" 🔥. Same parent, the "Mobile IPv6 Parameters" registry at <http://www.iana.org/assignments/mobility-parameters>. The status is a field in the Update Notification Acknowledgement message (Section 4.2), and IANA manages its number space under the "Update Notification Acknowledgement Status Registry". This spec reserves these type values, and the allocation policy is "Specification Required". Status codes between 0 and 127 mean the Update Notification message was processed successfully, and codes between 128 and 255 mean an error happened while processing it 😭

+=====+=====================================+=============+
|Value|       Description                   |  Reference  |
+=====+=====================================+=============+
| 0   | SUCCESS                             |  [RFC7077]  |
+=====+=====================================+=============+
|128  | FAILED-TO-UPDATE-SESSION-PARAMETERS |  [RFC7077]  |
+=====+=====================================+=============+
|129  | MISSING-VENDOR-SPECIFIC-OPTION      |  [RFC7077]  |
+=====+=====================================+=============+

11. References 📚

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💖
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. 🌸
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007. 🧚
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 🦋
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010. 💜
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. 🌈
[RFC6602] Abinader, F., Gundavelli, S., Leung, K., Krishnan, S., and D. Premec, "Bulk Binding Update Support for Proxy Mobile IPv6", RFC 6602, May 2012. ⭐

11.2. Informative References

[PMIPv6-FLOW-MOB] Bernardos, CJ., Ed., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", Work in Progress, October 2013. 🍓
[PMIPv6-QoS] Liebsch, M., Seite, P., Yokota, H., Korhonen, J., and S. Gundavelli, "Quality of Service Option for Proxy Mobile IPv6", Work in Progress, November 2013. 🫶
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 👑
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. 🌸
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 🎀
[RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010. 💅
[RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile IPv6", RFC 5847, June 2010. 🧚
[RFC6757] Gundavelli, S., Korhonen, J., Grayson, M., Leung, K., and R. Pazhyannur, "Access Network Identifier (ANI) Option for Proxy Mobile IPv6", RFC 6757, October 2012. 🦋
[RFC6909] Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R. Koodli, "IPv4 Traffic Offload Selector Option for Proxy Mobile IPv6", RFC 6909, April 2013. 💖

Authors' Addresses 💌

Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada

Phone: +1 514 345 7900 x42871 EMail: suresh.krishnan@ericsson.com

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

EMail: sgundave@cisco.com

Marco Liebsch NEC Kurfuersten-Anlage 36 D-69115 Heidelberg Germany

EMail: marco.liebsch@neclab.eu

Hidetoshi Yokota KDDI

EMail: yokota@kddilabs.jp

Jouni Korhonen Broadcom Porkkalankatu 24 Helsinki FIN-00180 Finland

EMail: jouni.nospam@gmail.com

📦 where this page comes from

ietf: rfc7077 2013-11
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 7077

Update Notifications for Proxy Mobile IPv6 ✨

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction 🧚

2. Conventions and Terminology 📚

2.1. Conventions

2.2. Terminology

3. Notification Message - Usage Examples 🎀

4. Message Formats ✨

4.1. Update Notification (UPN) 🔔

Sequence Number 🔢

Notification Reason 📣

Acknowledgement Requested Flag ((A) Flag) 🙋‍♀️

Retransmit Flag ((D) Flag) 🔁

Reserved 🫥

Mobility Options 🧩

4.2. Update Notification Acknowledgement (UPA) 💜

Sequence Number 🔢

Status Code 🚦

Reserved 🫥

Mobility Options 🧩

5. LMA Considerations 👑

5.1. Constructing the Update Notification Message 🎀

5.2. Receiving the Update Notification Acknowledgement Message 💌

6. MAG Considerations ✨

6.1. Receiving the Update Notification Message 💌

6.2. Constructing the Update Notification Acknowledgement Message 🎀

7. Protocol Configuration Variables ⚙️

8. Security Considerations 🔐

9. Acknowledgements 💖

10. IANA Considerations 🎀

11. References 📚

11.1. Normative References

11.2. Informative References

Authors' Addresses 💌