RFC 5846

Binding Revocation for IPv6 Mobility

📅 published June 2010, from ietf

RFC 5846: Binding Revocation for IPv6 Mobility 🎀

Part 1 of 10 🌸

Okay bestie, here's the whole setup. The authors are A. Muhanna and M. Khalil from Ericsson, S. Gundavelli and K. Chowdhury from Cisco, and P. Yegani from Juniper Networks. It's published as a Standards Track document, so it's an official Internet standard, and it came out in June 2010. It's an IETF product, and the ISSN is 2070-1721 ✨. The title block doesn't list anything it obsoletes or updates, so there's no drama there 💅.

Abstract ✨

Okay so this doc defines a binding revocation mechanism 🦋. Its whole job is to end a mobile node's mobility session and the resources tied to it. It works with base Mobile IPv6 and with its extensions, like Proxy Mobile IPv6. The mobility entity that starts the revocation can ask its peer to terminate one binding cache entry, several of them, or all of the specified ones. Iconic behaviour 👑.

Status of This Memo

This is an Internet Standards Track document 🔥.

It comes from the Internet Engineering Task Force (IETF), so it 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 info on Internet Standards, check Section 2 of RFC 5741 🧚.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5846 💜.

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.

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 🫶. Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License.

This document might include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🙈.

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
2.  Conventions and Terminology  . . . . . . . . . . . . . . . . .  4
  2.1.  Conventions Used in This Document  . . . . . . . . . . . .  4
  2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
3.  Binding Revocation Protocol and Use Cases Overview . . . . . .  5
  3.1.  Binding Revocation Protocol  . . . . . . . . . . . . . . .  5
  3.2.  MIPv6 and DSMIP6 Use Case  . . . . . . . . . . . . . . . .  6
  3.3.  Multiple Care-of Addresses (MCoA) Use Case . . . . . . . .  7
  3.4.  Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . .  8
    3.4.1.  Local Mobility Anchor Initiates PMIPv6 Revocation  . .  9
    3.4.2.  Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10
4.  Binding Revocation Messages over IPv4 Transport Network  . . . 10
5.  Binding Revocation Message . . . . . . . . . . . . . . . . . . 11
  5.1.  Binding Revocation Indication Message  . . . . . . . . . . 13
  5.2.  Binding Revocation Acknowledgement Message . . . . . . . . 16
6.  Binding Revocation Process Operation . . . . . . . . . . . . . 18
  6.1.  Sending Binding Revocation Message . . . . . . . . . . . . 18
    6.1.1.  Sending Binding Revocation Indication  . . . . . . . . 18
    6.1.2.  Sending Binding Revocation Acknowledgement . . . . . . 19
  6.2.  Receiving Binding Revocation Message . . . . . . . . . . . 20
    6.2.1.  Receiving Binding Revocation Indication  . . . . . . . 20
    6.2.2.  Receiving Binding Revocation Acknowledgement . . . . . 21
  6.3.  Retransmission of Binding Revocation Indication  . . . . . 22
7.  Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
8.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . . 23
  8.1.  Sending Binding Revocation Indication  . . . . . . . . . . 23
  8.2.  Receiving Binding Revocation Indication  . . . . . . . . . 27
9.  Mobile Access Gateway Operation  . . . . . . . . . . . . . . . 29
  9.1.  Receiving Binding Revocation Indication  . . . . . . . . . 29
  9.2.  Sending Binding Revocation Indication  . . . . . . . . . . 31
10. Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 32
11. Protocol Configuration Variables . . . . . . . . . . . . . . . 34
12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 34
13. Security Considerations  . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
  15.1. Normative References . . . . . . . . . . . . . . . . . . . 37
  15.2. Informative References . . . . . . . . . . . . . . . . . . 38

1. Introduction ✨

Okay so with Mobile IPv6, sometimes for administrative reasons you need to tell the mobile node that its registration got revoked 💀. From that point on, the mobile node can't receive IP mobility service for its Home Address anymore. IETF already has a similar thing for Mobile IPv4 registration revocation [RFC3543], which covers sessions set up with Mobile IPv4 registration [RFC3344]. Main character energy for revocation 👑.

This document specifies a binding revocation mechanism that can revoke a mobile node's mobility session(s). The same mechanism works for bindings created with Mobile IPv6 [RFC3775] or any of its extensions, like Proxy Mobile IPv6 [RFC5213] 🦋. It uses a new Mobility Header (MH) type 16 for revocation signaling. That applies to both Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213], and any two IP mobility entities can use it 🫶.

For example, a local mobility anchor (LMA) that's providing IP mobility services to a mobile node can use this to tell the mobile access gateway (MAG) that the mobile node's binding registration is over 🌸. Another example: a mobile access gateway can tell its local mobility anchor peer to bulk terminate all or some of the proxy mobile IPv6 (PMIPv6) bindings that are registered with that LMA and currently served by the MAG 🧚. Any mobility entity can only revoke the registrations of mobile node(s) mobility sessions that are currently registered with it. No overreaching allowed 💅.

2. Conventions and Terminology 🌈

2.1. Conventions Used 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 [RFC2119] 🔥.

2.2. Terminology

Basically, all the general mobility related terminology and abbreviations get interpreted the way they're defined in the Mobile IPv6 [RFC3775], Proxy Mobile IPv6 [RFC5213] and IPv4 Support for Proxy Mobile IPv6 [RFC5844] specs 📚. On top of that, this spec uses the following terms.

Initiator

The mobility node that starts the binding revocation procedure by sending a Binding Revocation Indication message to its peer, e.g., home agent, local mobility anchor, or mobile access gateway 🦋.

Responder

The mobility node that receives the Binding Revocation Indication message and replies with a Binding Revocation Acknowledgement message, e.g., mobile node, mobile access gateway, or local mobility anchor 💜.

3. Binding Revocation Protocol and Use Cases Overview ⭐

So this spec describes a generic binding revocation mechanism. A mobility node can tell the mobile node, or another mobility node, which mobile node registration binding is getting terminated 🎀. When this is used for bulk termination or for multiple bindings, the identities of those bindings get communicated with the same generic mechanism, which is honestly so clean 😭. The subsections below go over the protocol overview and the use cases that apply.

3.1. Binding Revocation Protocol ✨

Okay so, for Mobile IPv6, if the home network decides to end service for a mobile node, the home agent sends a Binding Revocation Indication (BRI) message to that mobile node 💌. The home agent puts the mobile node's home address (HoA) in the Type 2 routing header, as specified in [RFC3775], so it's crystal clear which binding is getting revoked. For Dual Stack Mobile IPv6 (DSMIPv6) [RFC5555], the home agent may also include the IPv4 Home Address option, carrying the home IPv4 address the mobile node was assigned 🧚. And if the mobile node registered multiple care-of addresses [RFC5648], the home agent includes the Binding Identifier (BID) option(s) in the BRI message so everyone knows exactly which binding is being revoked 🎀. When the mobile node gets a BRI with its HoA in the Type 2 routing header, it responds by sending a Binding Revocation Acknowledgement (BRA) message 🫶.

Similarly, for Proxy Mobile IPv6 [RFC5213], the local mobility anchor can start the revocation by sending a BRI message to tell the mobile access gateway that a registration binding is ending 🌸. Here the local mobility anchor includes the mobile node Home Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option [RFC4283], so the mobility access gateway can tell which PMIPv6 binding needs to be terminated. When the mobile access gateway receives the BRI, it replies to the local mobility anchor with a BRA message ✨.

On the flip side, the mobile access gateway usually sends a de-registration message: a Proxy Binding Update with a lifetime of zero, telling the local mobility anchor that the PMIPv6 mobile node binding registration is over 💅. In this case, the mobile access gateway includes the MN-HNP option, the MN-ID option, and all other required mobility options as per [RFC5213], so the local mobility anchor can identify the mobile node PMIPv6 binding. Also, when the mobile access gateway wants to do a bulk termination of PMIPv6 mobility sessions, it sends a BRI message with the Global (G) bit set and puts the mobile access gateway identity in the MN-ID option (see Section 9.2 and Section 8.2) 👑. When the local mobility anchor gets a bulk-termination BRI like that, it checks that the mobile access gateway is authorized to send one (see Section 13), and then processes the BRI accordingly. If the local mobility anchor processes the BRI successfully, it replies to the mobile access gateway with a BRA message 🦋.

In all of the above cases, the initiator of the binding revocation procedure (for example, the home agent, local mobility anchor, or mobile access gateway) uses the Revocation Trigger field in the BRI message to tell the receiving node why the revocation procedure was started 💜.

3.2. MIPv6 and DSMIP6 Use Case

This one is giving "the home agent needs to tell the mobile node its binding got revoked" energy 🥺. The binding revocation mechanism applies to Mobile IPv6 and DSMIPv6 session(s) when the home agent needs to inform the mobile node that its binding registration has been revoked, e.g., for an administrative reason. It also lets the user or the mobile node react to the revocation, e.g., by reinstating interrupted Mobile IPv6 services 🔥.

So in this case, the home agent sends a BRI message to tell the mobile node that its current mobile IPv6 (MIPv6) binding has been revoked and it can no longer receive IP mobility service 😭. The home agent includes the HoA in a Type 2 routing header as used in [RFC3775] and sets the Revocation Trigger field to a proper value, e.g., Administrative Reason. For a DSMIPv6 session, the home agent may additionally include the mobile-node-assigned IPv4 Home Address in the IPv4 Home Address option 🌈. When the mobile node receives the BRI message, it sends a BRA message back to the home agent. Figure 1 shows the message sequencing when a home agent revokes a mobile node binding registration 🍓.

      MN                                         HA
      |                                           |
      |           HoA in Type 2 Routing Hdr       |
      |<<<------------...  +  ...-----------------|
      |      BRI [seq.#, Revocation Trigger]      |
      |                                           |
      |                                           |
      | BRA (HoA in Dest. Option)[seq.#, Status]  |
      |---------------------------------------->>>|
      |                                           |
      |                                           |

Figure 1: Home Agent Revokes a Mobile Node Binding Registration

3.3. Multiple Care-of Addresses (MCoA) Use Case

Okay, MCoA is where things get extra juicy 🍭. With multiple care-of address registrations [RFC5648], the home agent maintains a different binding for each care-of address and home address pair. These bindings are also indexed and identified during the mobile node registration using a BID mobility option. The HA may revoke one or multiple bindings for the same mobile node home address 🧚‍♀️.

If the home agent revokes a single binding for a mobile node with multiple care-of address registrations, it sends a BRI message to the mobile node with the corresponding BID option included. If more than one of the mobile node's registered care-of addresses needs to be revoked, the home agent includes all the corresponding BID options in the same BRI message 💖. Figure 2 shows the message flow when the home agent revokes two registered care-of addresses for the same mobile node in a single BRI message.

                                                    HA Binding Cache
                                                    ================
                                                    MN-BID1 [CoA1+HoA]
   MN                                           HA  MN-BID2 [CoA2+HoA]
    |                                            |  MN-BID3 [CoA3+HoA]
    |                                            |  MN-BID4 [CoA4+HoA]
    |             HoA in Type 2 Routing Hdr      |
    |<<<<--------------  +  ---------------------|
    |     BRI [seq.#, R. Trigger, BID1, BID4]    |
    |                                            |
    |                                            |
    | BRA (HoA in Dest. Option) [seq.#, Status]  |
    |---------------------------------------->>>>|
    |                                            |
    |                                            |

Figure 2: Home Agent Revokes MN's Specific Care-of Address Bindings

Additionally, the home agent may revoke all of the mobile node's registered bindings by sending a BRI message without including any BID options while the HoA is included in the Type 2 routing header. Figure 1 shows the message flow when the home agent revokes all registered care-of address bindings for a mobile node in a single BRI message 🌷.

3.4. Proxy MIPv6 Use Case

Here's the tea 🫖: the mobile node doesn't take part in the mobility mechanism in PMIPv6, so there are lots of situations where binding revocation is needed to clean up resources and keep the mobility entities, i.e., the mobile access gateway and local mobility anchor, synced up on the status of existing PMIPv6 bindings 🧹. The binding revocation mechanism is generic enough to be used for all Proxy Mobile IPv6 scenarios that follow the [RFC5213] and [RFC5844] specifications 🌈.

When the mobile access gateway receives a BRI message as in Section 9.1, it sends a BRA message to the local mobility anchor following the rules described in Section 6.1.2. Similarly, if the local mobility anchor receives a BRI message, it responds to the mobile access gateway by sending a BRA message 💅✨.

3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation ✨

okay so the local mobility anchor (LMA) 💅 can send a Binding Revocation Indication (BRI) with the right revocation trigger value to the mobile access gateway (MAG) that's hosting a specific PMIPv6 binding. It's basically saying "hey, this mobile node's binding is done, go clean up your stuff" 🧹. When the MAG gets a BRI, it finds the binding it's talking about and sends back a Binding Revocation Acknowledgement (BRA) to the LMA. The MAG could also end the IPv6 or IPv4 mobility session on the access link and let the mobile node know, see Section 9.1 🫶.

Here's an example that's lowkey iconic 🦋. Figure 3 shows the message sequence for revoking a mobile node binding at the source MAG during an inter-MAG handover. So the mobile node moves from the source MAG to the target MAG. Then the target MAG sends a Proxy Binding Update (PBU) with the new care-of address to the LMA so it can update the mobile node's point of attachment. The LMA's binding for that mobile node still points to the source MAG. So once it gets that PBU from the target MAG, it updates the MN Binding Cache entry (BCE) and sends a Proxy Binding Acknowledgement (PBA) back to the target MAG 🌸. After that, the LMA can send a BRI with the appropriate revocation trigger value, for example inter-MAG handover - different Access Types, to the source MAG. This is so the source MAG cleans up the resources it reserved for that mobile node binding 🧚. The source MAG then answers with a BRA that says whether terminating the mobile node's binding worked or didn't 💜.

The same process can be used by the LMA in situations other than inter-MAG handover too. It just needs the proper revocation trigger value to tell the peer MAG that a specific PMIPv6 binding, or several bindings, have been revoked 🌈.

          oldMAG       newMAG                          LMA
            |             |                            |
            |             |        PBU                 |
            |             |--------------------------->|
            |             |                      PBU triggers
            |             |                   BRI Msg to oldMAG
            |             |                            |
            |             |        PBA                 |
            |             |<---------------------------|
            |             |                            |
            |             |                            |
            |    BRI [seq.#, R. Trigger, P bit, NAI]   |
            |<-----------------------------------------|
            |             |                            |
            |             |                            |
            |             |                            |
            |             |                            |
            |        BRA [seq.#, Status, P bit]        |
            |----------------------------------------->|
            |             |                            |
            |             |                            |

Figure 3: LMA Revokes an MN Registration During Inter-MAG Handover

The LMA can also send a BRI to say that every binding hosted by the peer MAG and registered with the LMA is being revoked. To do that, it sets the Global (G) bit, as described in Section 8.1 🎀.

3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 👑

Now the MAG can do the bulk version 🔥. It sends a BRI with the Global (G) bit set and the Revocation Trigger field set to "Per-Peer Policy". That means every mobility binding that's registered at the LMA and attached to the MAG is being revoked, see Section 9.2 💀.

When the LMA gets this BRI from the MAG, it first checks whether that MAG is authorized to use global revocations. Then it replies with the right status code by sending a BRA, as described in Section 6.1.2 🙈.

4. Binding Revocation Messages over IPv4 Transport Network ✨

In some deployments, the network between the MAG and the LMA might only support IPv4 transport 🍓. Another situation is when a mobile node that supports client mobile IPv6 roams onto an access network where only IPv4 addressing and transport is supported. In that case, the mobile node is required to register an IPv4 home address with its home agent using a mobile IPv6 Binding Update message 🌸.

If the Proxy Binding Update and Proxy Binding Acknowledgement messages, or the Binding Update and Binding Acknowledgement messages, are sent using UDP encapsulation [RFC5844] [RFC5555], then the Binding Revocation Messages are sent using that same UDP encapsulation 🦋. The same UDP source and destination port numbers and IPv4 addresses used for the Proxy Binding Update and Proxy Binding Acknowledgement (or the Binding Update and Binding Acknowledgement) messages MUST be used when transporting Binding Revocation Messages over IPv4 using UDP encapsulation. This part is literally non-negotiable 😭.

Here's how the swap works. The source UDP port number, destination UDP port number, source IPv4 address, and destination IPv4 address of the Binding Revocation Indication are set to the destination UDP port number, source UDP port number, destination IPv4 address, and source IPv4 address of the latest received and successfully processed Proxy Binding Update or Binding Update message, respectively. For more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, check [RFC5844] and [RFC5555], respectively 🧚.

5. Binding Revocation Message ✨

This section defines the Binding Revocation Message format using an MH Type 16, as shown in Figure 4 💖. The value in the Binding Revocation Type field tells you whether the message is a Binding Revocation Indication or a Binding Revocation Acknowledgement. If that field is set to 1, the message is a Binding Revocation Indication, see Section 5.1. But if the value is 2, it's a Binding Revocation Acknowledgement message, see Section 5.2 🌈.

    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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Payload Proto |  Header Len   |   MH Type     |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |  B.R. Type    |               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
    |                                                               |
    .            Binding Revocation Message Data                    .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Binding Revocation Message

Payload Proto 🎀 8-bit selector. See [RFC3775] for more details.

Header Len 💅 8-bit unsigned integer. It represents the length of the Mobility Header in units of 8 octets, excluding the first 8 octets. See [RFC3775] for more details.

MH Type 🦋 16, which identifies the mobility message as a Binding Revocation Message.

Reserved 😭 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver. This is one of those "don't mess with it" fields 🙈.

Checksum 🧁 16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is calculated as described in [RFC3775] 🔥.

Binding Revocation Type 👑 8-bit unsigned integer. It defines the type of the Binding Revocation Message and can be assigned one of the following values:

0  Reserved
1  Binding Revocation Indication
2  Binding Revocation Acknowledgement

All other values are unassigned

Binding Revocation Message Data 🌸 The Binding Revocation Message Data follows the Binding Revocation Message format defined in this document for the value set in the Binding Revocation Type field. In this document, it's either a Binding Revocation Indication, see Section 5.1, or a Binding Revocation Acknowledgement, see Section 5.2 ⭐.

5.1. Binding Revocation Indication Message ✨

Okay bestie, the Binding Revocation Indication (BRI) message is a Binding Revocation Message with MH type 16 and a Binding Revocation Type value of 1 🦋. The initiator uses it to tell the responder exactly which binding or bindings are getting revoked, so the IP mobility service for those ones is officially yeeted 💅. The BRI gets sent the way Sections 7, 8.1, and 9.2 describe.

When Binding Revocation Type is 1, the Binding Revocation Message Data follows the BRI layout shown in Figure 5 🎀

       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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       | B.R. Type = 1 |  R. Trigger   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          Sequence #           |P|V|G|       Reserved          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: Binding Revocation Indication Message

Revocation Trigger 🌸

This is an 8-bit unsigned integer that says which event made the initiator send the BRI 💖. Per-MN Revocation Trigger values are less than 128, and they're used when the BRI is revoking one or more bindings for the same mobile node. Global Revocation Trigger values are greater than 128 and less than 250, and they go in the BRI when the Global (G) bit is set for global revocation. Values 250-255 are reserved for testing purposes only. These are the trigger values defined right now:

Per-MN Revocation Trigger Values:
    0  Unspecified
    1  Administrative Reason
    2  Inter-MAG Handover - same Access Type
    3  Inter-MAG Handover - different Access Type
    4  Inter-MAG Handover - Unknown
    5  User-Initiated Session(s) Termination
    6  Access Network Session(s) Termination
    7  Possible Out-of-Sync BCE State

Global Revocation Trigger Values:
    128  Per-Peer Policy
    129  Revoking Mobility Node Local Policy

Reserved Revocation Trigger Values:
    250-255 Reserved For Testing Purposes only
    All other values are Reserved

Sequence Number 🍓

This is a 16-bit unsigned integer the initiator uses to match a returned Binding Revocation Acknowledgement with this BRI. It could be a random number. At any time, implementations MUST ensure there is no collision between the sequence numbers of all outstanding Binding Revocation Indication Messages 🙈

Proxy Binding (P) 🧚

The initiator sets the Proxy Binding (P) bit to say the revoked binding(s) is a PMIPv6 binding.

IPv4 HoA Binding Only (V) 🌈

The initiator, home agent, or local mobility anchor sets the IPv4 HoA Binding Only (V) bit to tell the receiving mobility entity that only the IPv4 Home Address binding is being terminated, as in Sections 7 and 8.1.

Global (G) 👑

The initiator, LMA, or MAG sets the Global (G) bit to indicate the termination of all Per-Peer mobility Bindings or Multiple Bindings that share a common identifier(s) and are served by the initiator and responder, as in Sections 8.1 and 9.2.

Reserved 🫶

These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.

Mobility Options 💜

This is a variable-length field, sized so the complete Mobility Header is an integer multiple of 8 octets long. It holds zero or more TLV-encoded mobility options. This document does not define any new mobility option. The receiver MUST ignore and skip any options that it does not understand. The responder uses these options to figure out the specific binding or bindings the initiator is asking to have revoked.

The following options are valid in a Binding Revocation Indication:

  • Home Network Prefix option [RFC5213]. This option MAY be used only when the (P) bit is set. This option MUST be present when the BRI is used to revoke a single Proxy MIPv6 Binding Cache entry.
  • Mobile Node Identifier option [RFC4283]. This option MUST be present when the (P) bit is set. Additionally, if the Global (G) bit is set by the mobile access gateway, this option MUST carry the MAG identity. In this specification, only the Mobile Node Identifier option with subtype 1 is required, and other subtypes are currently not supported.
  • Binding Identifier mobility option [RFC5648]. This option MUST be present if the initiator requests to terminate one binding of a multiple care-of address bindings for the same mobile node. The initiator may include more than one of the BID mobility options.
  • IPv4 Home Address option, which contains the mobile node home IPv4 address [RFC5555]. This option MUST only be included when the IPv4 HoA Binding only (V) bit is set and the (P) bit is cleared.
  • IPv4 Home Address Request option, which contains the mobile node proxy home IPv4 address [RFC5844]. This option MUST only be included when the IPv4 HoA Binding only (V) and the (P) bits are set.
  • Alternate Care-of Address mobility option [RFC3775]. According to [RFC5213], the mobile access gateway is allowed to include this option in the Proxy Binding Update to indicate the proxy care-of address of the mobile node mobility session. This option MAY be included to indicate the proxy care-of address of the mobile node's binding that is being revoked. In the case when the Global (G) bit is set, this option identifies all mobility bindings that share the same proxy care-of address.

If no mobility options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1 🌟

5.2. Binding Revocation Acknowledgement Message 🦋

The Binding Revocation Acknowledgement (BRA) message is a Binding Revocation Message with MH type 16 and a Binding Revocation Type value of 2. It's the "got it, bestie" reply 🫶 It acknowledges receipt of a Binding Revocation Indication message described in Section 5.1. This packet is sent as described in Section 6.1.2.

When Binding Revocation Type is 2, the Binding Revocation Message Data follows the BRA layout shown in Figure 6 🎀

       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
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       | B.R. Type = 2 |    Status     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Sequence #         |P|V|G|       Reserved          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Binding Revocation Acknowledgement Message

Status 🌸

This is an 8-bit unsigned integer that tells the initiator how the responder did processing the Binding Revocation Indication message 💅 Status values less than 128 mean the BRI was processed successfully by the responder. Values greater than or equal to 128 mean the BRI was rejected by the responder. These are the Status values defined right now:

0  success
1  partial success
128  Binding Does NOT Exist
129  IPv4 Home Address Option Required
130  Global Revocation NOT Authorized
131  Revoked Mobile Nodes Identity Required
132  Revocation Failed - MN is Attached
133  Revocation Trigger NOT Supported
134  Revocation Function NOT Supported
135  Proxy Binding Revocation NOT Supported

Sequence Number 🍓

The Sequence Number in the Binding Revocation Acknowledgement is copied from the Sequence Number field in the Binding Revocation Indication. The initiator (HA, LMA, or MAG, for example) uses it to match this Binding Revocation Acknowledgement with the outstanding Binding Revocation Indication 🧚

Proxy Binding (P) 💜

The Proxy Binding (P) bit is set if the (P) bit is set in the corresponding Binding Revocation Indication message.

IPv4 HoA Binding Only (V) 🌈

The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in the corresponding Binding Revocation Indication message.

Global (G) 👑

The Global (G) bit is set if the (G) bit is set in the corresponding Binding Revocation Indication message.

Reserved 🫶

These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.

Mobility Options 💖

This is a variable-length field, sized so the complete Mobility Header is an integer multiple of 8 octets long. It holds zero or more TLV-encoded mobility options. If the Status field is set to success, no mobility option is required. Usually the mobility option(s) carry info about the bindings that failed the revocation procedure ✨

The following mobility options are valid in a Binding Revocation Acknowledgement:

  • Home Network Prefix option [RFC5213]. This option MAY be included only when the (P) bit is set.
  • Mobile Node Identifier Option [RFC4283]. This option MAY be included when the (P) bit is set. This option SHOULD be included if the Home Network Prefix option is included.
  • Binding Identifier mobility option [RFC5648]. The responder MAY include this option to indicate the specific BID that failed the revocation procedure.

If no options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1 💅

6. Binding Revocation Process Operation 👑

Okay so this next bit is where the revocation process actually runs 🔥 The following subsections describe the details of the generic binding revocation process as used by the different mobility entities. Main character energy, no cap 🦋

6.1. Sending Binding Revocation Message

okay so sending a Binding Revocation message is giving "build it like any other Mobility Header" 💅 the initiator constructs the packet the usual way, with the ONE change being that the MH Type field gets set to 16 ✨

The Binding Revocation Message MUST be protected using the same underlying security association, e.g., IPsec, that's already protecting the mobile node's Mobile IPv6 and its extensions binding registration signaling between the two peers 🔐 bestie this part is NON-NEGOTIABLE 😭 If IPsec isn't the mechanism protecting that binding registration signaling, then whatever underlying security mechanism IS used MUST provide protection against all identified security threats, as described under "Security Considerations" in [RFC3775] and [RFC5213] 🛡️

6.1.1. Sending Binding Revocation Indication

The initiator MUST construct the Binding Revocation Message Data following the format of the Binding Revocation Indication message, as described in Section 5.1 and the following 🎀

  • The initiator MUST set the Sequence Number field to a valid sequence number for Binding Revocation. Sending a Binding Revocation Indication message isn't a daily thing, so a 16-bit Sequence Number field is big enough for the initiator to match the Binding Revocation Acknowledgement to the associated Binding Revocation Indication using the Sequence Number field only 🧚
  • If the initiator is revoking a binding that was created using proxy MIPv6 registration, the initiator MUST set the Proxy Binding (P) bit 🍓
  • If the initiator is sending the Binding Revocation Indication message to revoke multiple mobility sessions, the initiator MUST set the Global (G) bit. In this case, the initiator MUST also set the Revocation Trigger field to a valid value from the list of Global Revocation Triggers 🌸
  • If the initiator is sending the Binding Revocation Indication message with the Global (G) bit cleared, the initiator MUST set the Revocation Trigger field to a valid value from the list of Per-MN Revocation Triggers 💜
  • If the initiator is sending the Binding Revocation Indication message to indicate the revocation of the mobile node IPv4 HoA Binding Only, the initiator MUST set the (V) bit. In this case, the initiator MUST include either the IPv4 Home Address option or the IPv4 Home Address Request option in the BRI to identify the IPv4 HoA that's being revoked 🦋

6.1.2. Sending Binding Revocation Acknowledgement

The responder MUST send a Binding Revocation Acknowledgement message to show it received the corresponding Binding Revocation Indication message and what happened when it processed it 📬 the rules go like this:

  • Whenever the Binding Revocation Indication is discarded, e.g., as described in Section 6.2, a Binding Revocation Acknowledgement MUST NOT be sent. Otherwise, the treatment depends on the following rules 🙈
  • If the responder accepts the Binding Revocation Indication message, the responder MUST send a successful Binding Revocation Acknowledgement with an appropriate status code ✨
  • If the responder rejects the Binding Revocation Indication message, the responder MUST send a Binding Revocation Acknowledgement with an appropriate failure status code 💀

If the Source Address field of the IPv6 header that carried the Binding Revocation Indication message does not contain a unicast address, the Binding Revocation Indication packet MUST be silently discarded. no unicast, no ack, bye 👋

When the responder acknowledges the received Binding Revocation Indication message, the responder MUST construct the Binding Revocation Message Data following the format of the Binding Revocation Acknowledgement message, as described in Section 5.2 and the following 🌈

  • The responder MUST set the Sequence Number field by copying the value from the Sequence Number field of the received Binding Revocation Indication 🔁
  • The responder MUST set the Status field to a valid value that reflects the status of processing the received Binding Revocation Indication message 📊
  • If the (P) bit is set in the received Binding Revocation Indication, the responder MUST set the (P) bit in the Binding Revocation Acknowledgement 🍓
  • If the Global (G) bit is set in the received Binding Revocation Indication, the responder MUST set the Global (G) bit in the Binding Revocation Acknowledgement 🌸
  • If the IPv4 HoA Binding Only (V) bit is set in the received Binding Revocation Indication, the responder MUST set the (V) bit in the Binding Revocation Acknowledgement 🦋
  • The destination IP address of the IPv6 packet of the Binding Revocation Acknowledgement is set to the source IP address of the received Binding Revocation Indication 📍

6.2. Receiving Binding Revocation Message

when a Binding Revocation Message comes in, the responder MUST verify the Mobility Header as described in Section 9.2. of [RFC3775] 🕵️‍♀️ if the packet gets dropped because it fails any of the Mobility Header test checks, the responder MUST follow the processing rules in Section 9.2 of [RFC3775] 🚫 and if the responder doesn't support the Binding Revocation Indication message AND doesn't recognize MH type 16, it sends a Binding Error message with the Status field set to 2, as described in [RFC3775] 😭

Upon receiving a packet carrying a Binding Revocation Message, BRI or BRA, the receiving mobility entity MUST verify that the packet was received protected by the security association being used to protect the binding registration and Binding Revocation signaling between the two peers, e.g., an IPsec Security Association (SA) 🔐 security check, periodt 💅

6.2.1. Receiving Binding Revocation Indication

When the responder receives a packet carrying a Binding Revocation Indication message that was successfully processed as in Section 6.2, the responder ALSO processes the message as follows 👑

  • The responder MUST validate that the Binding Revocation Indication is formatted as in Section 5.1 🧾
  • If the Revocation Trigger field is set to a value the responder doesn't support, the responder SHOULD reject the Binding Revocation Indication message using status code Revocation Trigger NOT Supported 🙅‍♀️
  • If the Revocation Trigger value is NOT allowed with the Binding Revocation Indication message intent, e.g., the Global (G) bit is set and the Revocation Trigger field value is Per-MN-specific, the responder SHOULD reject the Binding Revocation Indication message using status code Revocation Function NOT Supported 🚩
  • If the responder failed to identify the mobile node(s) bindings identified in the Binding Revocation Indication message, the responder MUST reject the BRI using status code Binding Does NOT Exist 🔍

6.2.2. Receiving Binding Revocation Acknowledgement

When the initiator receives a packet carrying a Binding Revocation Acknowledgement message that was successfully processed as in Section 6.2, the initiator ALSO processes the message and checks the Status field like this 🧐

  • The initiator MUST validate that the sequence number in the Sequence Number field matches the sequence number of an outstanding Binding Revocation Indication that was sent by the initiator. If it doesn't match any outstanding Binding Revocation Indication messages, the initiator MUST silently discard the message, but MAY log the event 🗒️
  • If the Status field indicates that the Binding Revocation Indication was processed successfully, the initiator MUST delete the current timer and the mobile node(s) binding(s) and all associated resources 🧹✨
  • If the Status field indicates any value other than success, the initiator SHOULD examine any mobility options included in the Binding Revocation Acknowledgement. In this case, it's up to the initiator's local policy how to handle the mobile node binding. The initiator MAY log the appropriate event to reflect the received status 🫶

6.3. Retransmission of Binding Revocation Indication

if the initiator doesn't get a Binding Revocation Acknowledgement back for its outstanding Binding Revocation Indication before the InitMINDelayBRIs timer runs out, the initiator (e.g., an LMA) SHOULD retransmit the same BRI message, up to the BRIMaxRetriesNumber as defined in Section 11 🔁⏰

The retransmissions by the initiator MUST use an exponential back-off process, where the timeout period doubles with each retransmission, until either the initiator gets a response or the timeout period hits the value MAX_BRACK_TIMEOUT 📈 the initiator MAY keep sending these messages at this slower pace, up to the BRIMaxRetriesNumber 🐢

If the initiator still doesn't receive a Binding Revocation Acknowledgement message after the BRIMaxRetriesNumber retransmits have been sent, the initiator SHOULD clean up all resources associated with this mobile node binding. The initiator may log the event 🧹💖

7. Home Agent Operation ✨

okay so when the home agent wants to end a mobile node's registration and its current binding, it sends the mobile node a packet with a Binding Revocation Indication inside. Let's build this thing properly, bestie 💅

  • The Revocation Trigger field MUST be set so the mobile node knows why its IP mobility binding with the home agent is being revoked. 🫶 The mobile node can use the Revocation Trigger to take more steps if it needs to.
  • The Binding Revocation Indication MUST be sent using a Type 2 routing header that carries the mobile node's registered IPv6 home address for the binding being revoked. 🦋
  • The care-of address for the binding MUST be used as the destination address in the IPv6 header. 🌸
  • If the home agent only needs to revoke the mobile node's IPv4 home address binding, it MUST set the IPv4 HoA Binding Only (V) bit and MUST include the mobile node's registered IPv4 home address being revoked in the IPv4 Home Address option. 🎀

When the home agent sends a Binding Revocation Indication, it sets a flag in the mobile node's BCE to show that revocation is in progress, and it starts the InitMINDelayBRIs timer. ⏰ The BCE stays in this state until a Binding Revocation Acknowledgement comes back, or until the home agent retransmits the Binding Revocation Indication as described in Section 6.3. 🔁

Race condition alert 🚨: the home agent might get a Binding Update from the mobile node while that BCE still has the revocation-in-progress flag set. In that case the home agent SHOULD handle it based on why the Binding Revocation Indication was sent, plus its local policy. 🧠 If the home agent does accept the Binding Update, it needs to update the mobile node's BCE to match, for example by removing the revocation-in-progress flag. ✨

If the home agent needs to revoke one or more of a mobile node's bindings that were created with multiple care-of address registrations (see [RFC5648]), it MUST include all the related BID mobility options that identify those bindings in the Binding Revocation Indication message. 🧩 And if it's revoking all of the mobile node's bindings, the home agent SHOULD NOT include any of the BID mobility options. 🙈

When the home agent gets a packet with a valid Binding Revocation Acknowledgement message, it follows Section 6.2 to process it. 💖

8. Local Mobility Anchor Operation 🌈

8.1. Sending Binding Revocation Indication 💅

Okay bestie, so when the local mobility anchor wants to end a mobile node's PMIPv6 registration and its current binding 🦋, it sends a packet to the mobile access gateway with a Binding Revocation Indication message inside. It follows the procedure in Section 6.1 and these rules:

  • The Proxy Binding (P) bit MUST be set so it's crystal clear the binding being revoked is a PMIPv6 binding 💜
  • The Revocation Trigger field MUST be set to tell the mobile access gateway why that mobile node's PMIPv6 binding is getting removed at the local mobility anchor 🕵️ The Revocation Trigger may be used by the mobile access gateway to learn the mobile node's latest movement, so it's kinda a big deal 👀
  • The packet MUST contain the Mobile Node Identifier (MN-ID) option, which holds the mobile node's Network Access Identifier (NAI) that was used in the Proxy Binding Update during the mobile node registration 🎀
  • If the Mobile Node Identifier (MN-ID) is registered in more than one of the mobile node's BCEs and the local mobility anchor does NOT need to revoke all of the mobile node's bindings, the Binding Revocation Indication message MUST contain another identifier so it can uniquely identify the binding(s) being revoked. For example, at least one Home Network Prefix option that contains the mobile node's registered Home Network Prefix (HNP) for the binding being revoked 🌸
  • When revoking all Per-Peer bindings, the local mobility anchor MUST set the Global (G) bit and the Revocation Trigger MUST contain the value "Per-Peer Policy". This asks the mobile access gateway to remove all Per-Peer bindings that are registered with the local mobility anchor and this mobile access gateway ✨
  • The proxy care-of address for the binding MUST be used as the destination address in the packet's IPv6 header. BUT if IPsec is used to protect the Proxy MIPv6 signaling as specified in [RFC5213], the destination address MUST be set to the mag_address that is being used for keying the IPsec SA. If the mag_address is different than the mobile node proxy care-of address, the Alternate Care-of Address option MUST be included and MUST contain the mobile node proxy care-of address 🔥

The local mobility anchor MAY delete the mobile node(s) IP tunnel immediately after sending the initial Binding Revocation Indication, and before it receives the Binding Revocation Acknowledgement message 🧚

When the local mobility anchor sends a Binding Revocation Indication to the mobile access gateway to remove a specific binding, it sets a flag in the mobile node proxy BCE to show that revocation is in progress, and starts the InitMINDelayBRIs timer. The local mobility anchor SHOULD keep the mobile node proxy BCE in this state until it gets a Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. If the local mobility anchor sets the Revocation Trigger field to a value that indicates inter-MAG handover, it MAY switch the mobile node IP tunnel to the target mobile access gateway before sending the Binding Revocation Indication to the source mobile access gateway 🦋

In a race condition, the local mobility anchor may get a Proxy Binding Update from the mobile access gateway while the mobile node's proxy BCE still has the revocation in progress flag set. It should handle this based on the reason for sending the Binding Revocation Indication and its local policy. If the local mobility anchor accepts that Proxy Binding Update, it needs to update the mobile node proxy BCE accordingly, e.g., by removing the revocation in progress flag 💅

When the local mobility anchor needs to revoke all the mobile node proxy BCEs that are registered with it and the mobile access gateway peer, it MUST set the Global (G) bit and set the Revocation Trigger field to "Per-Peer Policy". In this case, the local mobility anchor MUST NOT include any mobility options in this Binding Revocation Indication message 🙈

When the local mobility anchor needs to revoke all mobile nodes' proxy BCEs that belong to a specific realm and are registered with it and the mobile access gateway peer, it MUST set the Global (G) bit and set the Revocation Trigger field to "Revoking Mobility Node Local Policy". It MUST include a mobility option in the Binding Revocation Indication that is shared among all the impacted mobile node BCEs, e.g., the mobile node identifier option, MN-ID option, with a subtype value of 1. The NAI value in the MN-ID MUST follow the format where the content after the @ character defines the realm shared amongst all of the impacted mobile node proxy BCEs. For example, @example.com identifies all mobile nodes whose MN-ID value contains example.com as the realm, e.g., 1234abdelta@example.com, axxxyzd@example.com, and abcdefg.xyz123@example.com, but NOT 1234abdelta@foo.example.com 🌈

When the local mobility anchor needs to revoke a subgroup of the mobile node proxy BCEs that belong to a specific realm and are registered with it and the mobile access gateway, it MUST set the Global (G) bit and set the Revocation Trigger field to "Revoking Mobility Node Local Policy". It MUST include an additional mobility option to the mobile node identifier option (MN-ID) option, with a subtype value of 1. In other words, the impacted mobile node BCEs are those that have an MN-ID with a realm as specified above and, e.g., are assigned the same proxy care-of address as the one included in the Alternate Care-of Address mobility option 🍓

When the mobile node is registered with multiple Home Network Prefixes for the same proxy care-of address, the local mobility anchor SHOULD include an HNP option for each registered HNP in the Binding Revocation Indication. Alternatively, it MAY include only the mobile node identifier (MN-ID) option with the mobile node NAI included, to tell the mobile access gateway to remove all bindings of the specified mobile node NAI in the MN-ID option 🫶

According to the Proxy Mobile IPv6 specification [RFC5213], if the local mobility anchor receives a Proxy Binding Update from a new mobile access gateway to extend the binding lifetime of the only BCE of this mobile node, with the Handoff Indicator set to "Handoff state unknown (4)", it waits for MaxDelayBeforeNewBCEAssign to receive a de-registration message from the previous mobile access gateway before updating the mobile node's BCE with the new point of attachment. If no de-registration message arrives, the local mobility anchor treats the received Proxy Binding Update as a request for a new BCE and, if it's processed successfully, assigns a different HNP for the new BCE 😭

This document updates the local mobility anchor's behavior in this case 📣 If the local mobility anchor supports the binding revocation mechanism described here, it SHOULD proactively send a Binding Revocation Indication message to the previous mobile access gateway instead of waiting for a de-registration from it. In that Binding Revocation Indication message, the Revocation Trigger MUST be set to "Inter-MAG Handover - Unknown" 👑

If the local mobility anchor sent a Binding Revocation Indication with the Revocation Trigger field set to "Inter-MAG Handover - Unknown", then while it's waiting for a response (the Binding Revocation Acknowledgement), these are the possible conditions it MUST handle as specified below:

  • If the local mobility anchor receives a successful Binding Revocation Acknowledgement message, or a de-registration message from the previous mobile access gateway, it MUST update the mobile node BCE as if it had received a de-registration message, as described in [RFC5213] 🌸
  • If the local mobility anchor receives a Binding Revocation Acknowledgement message with the Status field set to "Revocation Failed - MN is Attached", it SHOULD update the mobile node BCE as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expired, by creating a new BCE as described in [RFC5213] 🦋
  • If the local mobility anchor did not receive a Binding Revocation Acknowledgement message, or a de-registration Proxy Binding Update from the previous mobile access gateway, after it exhausted all of the Binding Revocation Indication message retransmissions as described in Section 6.3, it SHOULD update the mobile node's BCE as if it did NOT receive a de-registration before the MaxDelayBeforeNewBCEAssign timer expired, by creating a new BCE as described in [RFC5213]. Note that the local mobility anchor SHOULD use the recommended number of retransmissions for the Binding Revocation Indication message as described in Section 11, so it doesn't delay creating a new Binding Cache entry for too long if the mobile node is actually attaching to the new MAG with a different interface 🧚

When the mobile node is registered with an IPv4 proxy home address in addition to the Home Network Prefix, and both the IPv4 proxy HoA (pHoA) and the HNP are bound to the same proxy CoA (pCoA), the local mobility anchor MAY revoke the mobile node IPv4 proxy HoA binding to the current mobile node proxy CoA while keeping the mobile node binding of the HNP to its current pCoA as part of the mobile node BCE 🍓 In this case, if the local mobility anchor decides to revoke only the mobile node IPv4 proxy HoA, it MUST send a Binding Revocation Indication message following the procedure in Section 6.1 and these rules:

  • The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to indicate that only the IPv4 home address binding is being revoked 💜
  • The IPv4 Home Address Request option MUST be included with the mobile node's registered proxy home IPv4 address that is being released, in addition to the MN-ID option 🎀
  • The mobile node Home Network Prefix option MUST NOT be included 🙈
  • The Revocation Trigger field MUST be set to an appropriate value, e.g., "User Initiated Session(s) Termination" 🌈

8.2. Receiving Binding Revocation Indication 💌

okay so this is where the LMA gets a packet carrying a Binding Revocation Indication that already passed the Section 6.2 checks ✨. Then it runs through this checklist 💅:

  • If the (P) bit is set, the local mobility anchor MUST validate that all impacted bindings have the proxy binding flag set.
  • If the Global (G) bit is set and the Revocation Trigger field value is "Per-Peer Policy", the LMA MUST validate that the Proxy (P) bit is set and the MN-ID option is present with the mobile access gateway identity included. In addition, the local mobility anchor MUST verify that the identified mobile access gateway as per the value in the MN-ID option is authorized to use the global revocation with revocation trigger value "Per-Peer Policy", see Section 13. If the local mobility anchor processes the Global Binding Revocation Indication message successfully, it MUST accept the Binding Revocation Indication message using the status code "success". 🎀
  • If the mobile access gateway is not authorized to use the Per-Peer Global revocation feature or the received Binding Revocation Indication message has the Global (G) bit set and the Revocation Trigger field is set to "Per-Peer Policy", but the MN-ID option is not included, the local mobility anchor MUST reject the Binding Revocation Indication message using status code "Global Revocation NOT Authorized". 🙈
  • If the Global (G) bit is set and the Revocation Trigger value is "Per-Peer Policy", and only the mobile node identifier (MN-ID) option is included, the local mobility anchor MUST revoke all mobile node bindings for which the proxy CoA is the one used as the source of the IPv6 packet that carried the Binding Revocation Indication. However, if the Alternate Care-of Address option is included in addition to the mobile node identifier option, the local mobility anchor MUST revoke all mobile node bindings whose proxy care-of address matches the care-of address in the Alternate Care-of Address option. After the local mobility anchor successfully processes the Binding Revocation Indication message and identifies all impacted mobile nodes bindings, it MUST accept the Binding Revocation Indication message using the status code "success". 🦋
  • If the local mobility anchor accepted the Binding Revocation Indication message but one or more of the bindings identified in the received Binding Revocation Indication message has already been released, the local mobility anchor MUST accept the message and it MAY set the Status field to "partial success" and include the mobile node identifier (MN-ID) or the Home Network Prefix option to identify the binding(s) that failed the revocation procedure. 🌸
  • If the Global (G) bit is not set, the local mobility anchor uses the included mobility options to identify the impacted mobile node binding as follows:
    1. If only the mobile node identifier (MN-ID) option is included, the local mobility anchor MUST accept the message and revoke all bindings for this mobile node that use the specified mobile node NAI including the IPv4 Home Address binding(s) if present.
    2. If the mobile node identifier (MN-ID) and one Home Network Prefix option are included, the local mobility anchor MUST accept the message and only remove the specified mobile node proxy binding.
    3. If the mobile node identifier (MN-ID) option and more than one Home Network Prefix options are included, the local mobility anchor MUST accept the message and remove all bindings that are referenced by these Home Network Prefixes for the specified mobile node NAI.
    4. If the IPv4 HoA binding Only (V) bit is set and the mobile node identifier (MN-ID) option and the IPv4 Home Address Request option are included, the local mobility anchor MUST accept the message and remove only the IPv4 HoA address binding to the mobile node current proxy care-of address. 🧚

The Revocation Trigger field value in the received Binding Revocation Indication could be used by the local mobility anchor to log an event or update some local parameters that track the state of the peer mobile access gateway. 📝

After the local mobility anchor accepts or rejects a Binding Revocation Indication message, the local mobility anchor MUST follow Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement message to the mobile access gateway. 💜

9. Mobile Access Gateway Operation 🌈

9.1. Receiving Binding Revocation Indication 🫶

so now we flip to the MAG side 🔥. When the mobile access gateway gets a packet carrying a Binding Revocation Indication that was successfully processed as in Section 6.2, it goes through these checks:

  • If the Global (G) bit is set and the Revocation Trigger field value is "Per-Peer Policy", the mobile access gateway MUST validate that the Proxy (P) bit is set and no mobility options are included in the message. If the mobile access gateway processes the Global Binding Revocation Indication message successfully, it MUST accept the Binding Revocation Indication message using the status code "success". ⭐
  • If the Global (G) bit is set and the Revocation Trigger field value is "Revoking Mobility Node Local Policy", the mobile access gateway MUST validate that the Proxy (P) bit is set and at least the MN-ID option with the subtype value of 1 is included in the Binding Revocation Indication and it is formatted as described is Section 8.1. If the mobile access gateway processes this Global Binding Revocation Indication message successfully, it MUST accept the message using the status code "success". 💖
  • If the Global (G) bit is set and the Revocation Trigger field value is "Revoking Mobility Node Local Policy", and no mobility options are included in the Binding Revocation Indication message or the mobile access gateway is not able to identify the impacted mobile nodes bindings based on the included mobility options, the mobile access gateway MUST treat this as an error scenario. In this case, the mobile access gateway MUST reject the Binding Revocation Indication message using status code "Revoked Mobile Nodes Identity Required". 💀
  • If the Revocation Trigger field value in the received Binding Revocation Indication message indicates inter-MAG handover, e.g., Inter-MAG Handover - Unknown, the mobile access gateway uses the mobility option(s) included in the Binding Revocation Indication message to identify the mobile node binding. The mobile access gateway SHOULD ensure that the mobile node is no longer attached to the mobile access gateway before accepting the BRI message using status code "success". However, if the mobile access gateway verified that the mobile node is still directly attached, the mobile access gateway MUST reject the BRI using status code "Revocation failed - MN is Attached". 🍓
  • If the IPv4 HoA Binding Only (V) bit is set, the mobile access gateway uses the MN-ID option to identify the mobile node binding entry in the Binding Update List (BUL). The mobile access gateway MUST verify that the IPv4 address included in the IPv4 Home Address Request option in the received Binding Revocation Indication is the same as the IPv4 proxy HoA that is assigned to the mobile node. After the mobile access gateway successfully validates the received IPv4 home address as the mobile node IPv4 HoA, it MUST consider this as an indication to ONLY release the mobile node IPv4 proxy HoA binding to the mobile node current proxy CoA. Consequently, it MUST continue to maintain the mobile node IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA as part of the mobile node binding in the BUL entry and release all resources associated with the MN IPv4 proxy HoA binding to the MN pCoA. If the mobile access gateway processed the BRI successfully, the mobile access gateway MUST accept the BRI using status code "success". On the other hand, if the mobile access gateway is able to identify the mobile node binding using the MN-ID but failed to identify the received IPv4 proxy HoA, the mobile access gateway MUST reject the BRI using status code "Binding Does NOT Exist". 🦋
  • If the mobile access gateway accepts the Binding Revocation Indication message but one or more of the bindings identified in the received Binding Revocation Indication message has already been released before processing the Binding Revocation Indication, the mobile access gateway MUST accept the Binding Revocation Indication message. In this case, the mobile access gateway MAY set the Status field to "partial success" and include the mobile node identifier (MN-ID) or the Home Network Prefix option to identify the binding(s) that failed to be removed as part of the revocation procedure. 🌸

The Revocation Trigger field value in the received Binding Revocation Indication could be used by the mobile access gateway to define what actions the mobile access gateway could do to inform the mobile node that its IP connectivity to the current HNP has been terminated, e.g., if the Revocation Trigger field is set to "Administrative Reason", the mobile access gateway may terminate the IPv6 or IPv4 mobility session on the access link and notify the mobile node. The specific details and considerations on how the mobile access gateway terminates IPv6 or IPv4 mobility session on the access link and notifies the mobile node can be found in [RFC5213] and [RFC5844]. 🧁

After the mobile access gateway accepts or rejects a Binding Revocation Indication message, the mobile access gateway MUST follow Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement message to the local mobility anchor. 👑

9.2. Sending Binding Revocation Indication ✨

okay so the mobile access gateway (MAG) could send a Binding Revocation Indication message to wrap up multiple mobile node bindings in one go 🧚, e.g., when using the global revocation with the Global (G) bit set. In that situation, whenever something happens that means the MAG has to tell its local mobility anchor (LMA) peer to end all the mobile node bindings registered at both the LMA and the MAG, the MAG sends a Binding Revocation Indication message following the procedure in Section 6.1 and the following:

  • The Proxy Binding (P) bit MUST be set to indicate that the binding(s) being revoked is a PMIPv6 binding. 🌸
  • The Global (G) bit MUST be set and the Revocation Trigger MUST contain a value of "Per-Peer Policy" in the Binding Revocation Indication to request the local mobility anchor to remove all Per-Peer bindings that are registered with the local mobility anchor and the mobile access gateway. In this case, the MN-ID option MUST be included in the Binding Revocation Indication and contain the mobile access gateway identity. In addition, the mobile access gateway MAY include the Alternate Care-of Address option. If included, the Alternate Care-of Address option MUST contain the proxy care-of address the bindings that are being impacted by this Binding Revocation Indication message. 💅
  • The mobile access gateway address MAY be used as the source address in the packet's IPv6 header. 🦋

As described in Section 6.3, the mobile access gateway SHOULD retransmit the Binding Revocation Indication to the local mobility anchor until it receives a matching Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile access gateway MAY delete the mobile node IP tunnels immediately after sending the Binding Revocation Indication and before receiving a Binding Revocation Acknowledgement message from the LMA. 🫶

In response to a Binding Revocation Indication message, if the mobile access gateway receives a packet carrying a Binding Revocation Acknowledgement that was successfully processed as in Section 6.2 and the Status field indicates "Global Revocation NOT Authorized", the mobile access gateway is not authorized to participate in a Per-Peer Global Revocation. The mobile access gateway SHOULD NOT retry sending a Binding Revocation Indication with the Global (G) bit set and the Revocation Trigger field value set to "Per-Peer Policy" to the same local mobility agent. The mobile access gateway should raise an alarm or log an event to indicate this rejection. 🚨

Hot tip bestie: that "Global Revocation NOT Authorized" status is a hard no for Per-Peer Global Revocation, so don't keep knocking on the same door 😭

10. Mobile Node Operation 🎀

Upon receiving a packet carrying a Binding Revocation Indication, the mobile node MUST validate the packet according to Section 6.2 and the following tests:

  • The mobile node MUST verify that the IP address in the Type 2 routing header is its Home Address and that its Binding Update List contains an entry for that Home Address. If one of the tests fails, the mobile node SHOULD silently discard the received Binding Revocation Indication message. 🙈
  • If mobile node Binding Update List contains an entry for the IP address in the Type 2 routing header of the received Binding Revocation Indication packet, the mobile node MUST accept the BRI message using status code "success". ✨
  • If the IPv4 HoA Binding Only (V) bit is set in the received BRI message, the mobile node MUST verify that there is an IPv4 Home Address option in the received Binding Revocation Indication and the IPv4 address included in the IPv4 Home Address option is the same as its IPv4 HoA that is assigned to the mobile node. If this verification is successful, the mobile node MUST consider this Binding Revocation Indication as an indication to ONLY release the mobile node IPv4 HoA binding to its current care-of address. Consequently, the mobile node MUST continue to maintain its IPv6 HoA binding to the current CoA as part of the mobile node binding in the BUL entry and release all resources associated with the MN IPv4 HoA binding. In this case, the mobile node MUST accept the Binding Revocation Indication message using status code "success". On the other hand, if the IPv4 Home Address Option was NOT included in the received BRI with the (V) bit is set, the MN MUST reject the BRI message with status code "IPv4 Home Address Option Required". Additionally, if the IPv4 HoA received in the IPv4 Home Address Option is NOT the one assigned to the mobile node, the mobile node SHOULD reject the Binding Revocation Indication with status code "Binding Does NOT Exist". 🌈
  • The mobile node MUST verify that the (P) bit in the Binding Revocation Indication is NOT set. If the (P) bit is set, the mobile node MUST reject the Binding Revocation Indication using status code "Proxy Binding Revocation NOT Supported". 💀
  • If the mobile node has registered multiple care-of addresses with its home agent, the mobile node MUST verify which binding is being revoked by examining the content of the Binding Revocation Indication message. If the mobile node received a Binding Revocation Indication with one or more BID options and its home address is included in the Type 2 routing header, the mobile node MUST consider all of the care-of addresses bindings, identified in the BID options, with this home address as being revoked. In this case, if the BRI validation is successful, the mobile node MUST accept the Binding Revocation Indication message with status code "success". 👑
  • If the mobile node has multiple care-of address bindings with its home agent and received a Binding Revocation Indication, without any BID option included and its home address was included in the Type 2 routing header, the mobile node MUST consider all of its registered care-of address bindings with this home address as being revoked. If the mobile node validates the BRI successfully, the mobile node MUST accept the Binding Revocation Indication message with status code "success". 💜

If the mobile node accepts or rejects the Binding Revocation Indication message, the mobile node MUST follow Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement message to the home agent. Note that anytime the MN does not send a Binding Revocation Acknowledgement to a BRI, the initiator is likely to retransmit the BRI at least one time. This causes additional load on the initiator who sends the retransmissions, as well as on the MN that will receive and process them. 😭

The Revocation Trigger field value in the received Binding Revocation Indication could be used by the mobile node to define what action the mobile node could do to be able to register again and receive its IP mobility service, e.g., contacting its home operator. 🍓

11. Protocol Configuration Variables 🌸

Any mobility entity that is allowed to invoke the binding revocation procedure by sending a Binding Revocation Indication message SHOULD allow the following variables to be configured. 💖

BRI Maximum Number of Retries (BRIMaxRetriesNumber)

This variable specifies the maximum Number of times a mobility entity can retransmit a Binding Revocation Indication message before receiving a Binding Revocation Acknowledgement message. The default value for this parameter is 1. 🔥

Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)

This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but is not to be configured to less than 0.5 seconds. ⭐

Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)

This variable specifies the maximum delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 2 seconds. 🦋

12. IANA Considerations 🌈

This specification defines a new Binding Revocation Message using a new Mobility Header Type 16, as described in Section 5. The new Mobility Header type value needs to be assigned from the same numbering space as allocated for the other Mobility Header types registry. 🧚

This document also creates a new registry "Binding Revocation Type" that indicates the type of the binding revocation message. The current binding revocation message types are described in Sections 5.1 and 5.2, and are the following:

    0  Reserved
    1  Binding Revocation Indication
    2  Binding Revocation Acknowledgement
    All other values are unassigned

Future values of the Binding Revocation Type can be allocated using Standards Action or IESG Approval [RFC5226].

In addition, this document also creates a second new registry for the Revocation Trigger that indicates the reason behind sending the Binding Revocation Indication message. The current Revocation Trigger values are described in Section 5.1, and are the following:

Per-MN Revocation Trigger Values:

    0  Unspecified
    1  Administrative Reason
    2  Inter-MAG Handover - same Access Type
    3  Inter-MAG Handover - different Access Type
    4  Inter-MAG Handover - Unknown
    5  User-Initiated Session(s) Termination
    6  Access Network Session(s) Termination
    7  Possible Out-of-Sync BCE State

Global Revocation Trigger Values:

    128  Per-Peer Policy
    129  Revoking Mobility Node Local Policy

Reserved Revocation Trigger Values:

    250-255 Reserved For Testing Purposes only
    All other values are Unassigned

Future values of the Revocation Trigger can be allocated using Standards Action or IESG Approval [RFC5226].

Furthermore, this document creates a third new registry "Binding Revocation Acknowledgement Status Codes". The current values are described in Section 5.2, and are the following:

      0  success
      1  partial success
    128  Binding Does NOT Exist
    129  IPv4 Home Address Option Required
    130  Global Revocation NOT Authorized
    131  Revoked Mobile Nodes Identity Required
    132  Revocation Failed - MN is Attached
    133  Revocation Trigger NOT Supported
    134  Revocation Function NOT Supported
    135  Proxy Binding Revocation NOT Supported

Future values of the Status field can be allocated using Standards Action or IESG Approval [RFC5226].

All fields labeled "Reserved" are only to be assigned through Standards Action or IESG Approval. 💅

13. Security Considerations 🔐

Okay, this section is where things get serious, bestie, so let's go. 🫶 This spec lets the mobility node that starts the binding revocation procedure revoke a mobility session that's currently registered with it. It is not allowed for any mobility node to revoke a mobile node mobility session that isn't registered with that node. No sneaky revoking, periodt. 💅

The binding revocation protocol here uses the same security association between the mobile node and the home agent, or between the mobile access gateway and the local mobility anchor, that's already used to exchange the MIPv6 or PMIPv6 Binding Update and Binding Acknowledgement signaling. 🦋 If IPsec is used, the traffic selectors for the Security Policy Database (SPD) entry protecting the Binding Update and Binding Acknowledgement MUST be extended to include Binding Revocation Message MH type 16. Extending those traffic selectors means the existing SAs get reused instead of new ones being made, so they're already up and running when the revoking entity needs to send a binding revocation signaling message. Genius, right? ✨

Now, if IPsec is not the underlying security mechanism protecting the Mobile IPv6 and its extensions binding registration signaling, then the security mechanism that IS used MUST provide protection against all the identified security threats described under "Security Considerations" in [RFC3775] and [RFC5213]. No skipping that part. 🚨

Here's the tea 🍵: some mobility entities, like the local mobility anchor and the mobile access gateway, are allowed to send and receive Binding Revocation Indications and Binding Revocation Acknowledgements in different cases. So when IPsec secures the signaling between the local mobility anchor and the mobile access gateway, it stops any of them from processing a Binding Revocation Message that wasn't built by an authorized party. Main character protection energy. 👑

The Proxy Mobile IPv6 [RFC5213] spec says the local mobility anchor has to restrict creating and manipulating proxy bindings to specifically authorized mobile access gateways. So the mobile access gateway that's allowed to create or manipulate the mobile node proxy BCE is also allowed to revoke that mobile node registration, by sending a de-registration with a lifetime of zero. 🌸

⚠️ Bulk termination is the big one. When a Binding Revocation Indication has the Global (G) bit set and the Revocation Trigger field is set to "Per-Peer Policy", it impacts ALL the mobility sessions registered with the mobile access gateway and its local mobility anchor peer. That's a LOT, so the local mobility anchor MUST be locally configurable to authorize that specific functionality. 😭 Other stuff like a policy store or Authentication, Authorization, and Accounting (AAA) may be used too, but those are outside the scope of this spec. Just so you know. 🙈

14. Acknowledgements 💖

Huge thank-yous to Ryuji Wakikawa, Bruno Mongazon-Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay Devarapalli, and Joel Hortelius 🫶 for reviewing and commenting on this document, plus all the colleagues who helped move this effort forward. 🌈

We also want to thank Jari Arkko, Ben Campbell, Pasi Eronen, Ralph Droms, Alexey Melnikov, Tim Polk, Adrian Farrel, and Robert Sparks for their reviews as part of the IESG review process. You all are iconic. ⭐

15. References 📚

15.1. Normative References

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

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

[RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
           in IPv6", RFC 3775, June 2004.

[RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
           Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
           (MIPv6)", RFC 4283, November 2005.

[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.

[RFC5648]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
           and K. Nagami, "Multiple Care-of Addresses Registration",
           RFC 5648, October 2009.

[RFC5555]  Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
           Routers", RFC 5555, June 2009.

15.2. Informative References

[RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
           August 2002.

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

Authors' Addresses 🌷

Ahmad Muhanna
Ericsson, Inc.
2201 Lakeside Blvd.
Richardson, TX  75082
USA

EMail: ahmad.muhanna@ericsson.com


Mohamed Khalil
Ericsson, Inc.
6300 Legacy Dr.
Plano, TX  75024
USA

EMail: mohamed.khalil@ericsson.com


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

EMail: sgundave@cisco.com


Kuntal Chowdhury
Cisco
30 International Place
Tewksbury, MA  01876
USA

EMail: kchowdhu@cisco.com


Parviz Yegani
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA  94089
USA

EMail: pyegani@juniper.net
📦 where this page comes from