RFC 6602

Bulk Binding Update Support for Proxy Mobile IPv6

📅 published May 2012, from ietf

Bulk Binding Update Support for Proxy Mobile IPv6 🎀

Okay bestie, first the title block tea ☕. This is RFC 6602, called "Bulk Binding Update Support for Proxy Mobile IPv6". It's a Standards Track doc from May 2012 (ISSN 2070-1721). The authors are F. Abinader, Ed. (Instituto Nokia de Tecnologia), S. Gundavelli, Ed. (Cisco), K. Leung (Cisco), S. Krishnan (Ericsson), and D. Premec (Unaffiliated). The title block doesn't say it obsoletes or updates anything. 💅

Abstract 🦋

Okay so, to keep a mobility session alive for longer, the Proxy Mobile IPv6 spec says the mobile access gateway has to send a Proxy Binding Update message to the local mobility anchor for each session, one by one 😩. There aren't any signaling semantics for doing things to a whole group at once, so you end up with a LOT of periodic signaling traffic between a given mobile access gateway and a local mobility anchor. This doc defines optimizations to the binding update and revocation operations in Proxy Mobile IPv6, so you can act on a group-specific scope using a group identifier. It's giving efficiency 🔥.

Status of This Memo 🌸

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Info about the current status of this doc, any errata, and how to give feedback on it lives at http://www.rfc-editor.org/info/rfc6602 🧚

Copyright (c) 2012 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) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. 🫶

Table of Contents 🍓

1. Introduction ....................................................3
2. Conventions and Terminology .....................................4
   2.1. Conventions ................................................4
   2.2. Terminology ................................................4
3. Bulk Binding Update Overview ....................................4
   3.1. Motivation .................................................4
   3.2. General Operation ..........................................5
4. Message Formats .................................................8
   4.1. Extensions to Proxy Binding Update Message .................9
   4.2. Extensions to Proxy Binding Acknowledgement Message .......10
   4.3. Mobile Node Group Identifier Option .......................10
   4.4. Status Codes ..............................................11
5. Protocol Considerations ........................................12
   5.1. MAG Considerations ........................................12
        5.1.1. Extensions to Binding Update List Entry
               Data Structure .....................................12
        5.1.2. Requesting Bulk Binding Update Support for
               a Mobility Session .................................12
        5.1.3. Supporting Bulk Binding Updates ....................14
   5.2. LMA Considerations ........................................15
        5.2.1. Extensions to Binding Cache Entry Data Structure ...15
        5.2.2. Enabling Bulk Binding Update Support for a
               Mobility Session ...................................16
        5.2.3. Supporting Bulk Binding Updates ....................18
6. Protocol Configuration Variables ...............................20
   6.1. Local Mobility Anchor - Configuration Variables ...........20
   6.2. Mobile Access Gateway - Configuration Variables ...........20
7. IANA Considerations ............................................20
8. Security Considerations ........................................21
9. Acknowledgements ...............................................21
10. References ....................................................22
    10.1. Normative References .....................................22
    10.2. Informative References ...................................22

1. Introduction ✨

Okay, so the Proxy Mobile IPv6 base spec [RFC5213] requires the Mobile Node Identifier option to be present in the mobility signaling messages, like the Proxy Binding Update (PBU) and Proxy Binding Acknowledgement (PBA) messages. That basically limits the operational scope of a binding update to a single mobility session 🙈. These messages have no way to identify a group of mobility sessions, so binding update and revocation can't hit all the sessions in a group at once.

There's a need for semantics that attach a group identity to a mobility session, so the scope of binding update and revocation can stretch to every mobility session that the group identifier points to. The group identifier is a major upgrade for protocol operations that would otherwise need multiple atomic transactions, one per mobility session. Here are some use cases where it shines 💖:

  • For extending the lifetime of a mobility session, the mobile access gateway (MAG) periodically sends a Proxy Binding Update message to the local mobility anchor (LMA) on a per-session basis. This can be optimized by letting the mobile access gateway send a single Proxy Binding Update [RFC5213] message for a group of mobility sessions identified by a group identifier. Once the request is accepted, the local mobility anchor can update the lifetime of all the mobility sessions in that group.
  • When a specific service card fails, or a local mobility anchor or a mobile access gateway service hosted on a blade architecture system goes down, it can potentially ask its peer to revoke all the sessions that share a common group identifier and are hosted on that service card. Potentially, one Binding Revocation Indication [RFC5846] message carrying the group identifier can revoke all the sessions hosted on that service card, which would otherwise need to be handled per session.

This document defines a new mobility option, the Mobile Node Group Identifier option, and the extensions to the binding update and binding revocation procedures for doing binding operations with group-specific scope 🦋.

2. Conventions and Terminology 🌈

2.1. Conventions

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 used in this document are to be interpreted as defined in the base Proxy Mobile IPv6 specifications [RFC5213] and [RFC5844]. On top of that, this doc uses the following terms 📚:

Bulk Binding Update

A binding update operation that has group-specific scope. A binding operation is associated with one specific mobility session, but a bulk binding update operation is associated with multiple mobility sessions. This operation isn't relevant for creating new mobility sessions.

Bulk Binding Update Group

A group of mobility sessions that belong to the same logical group and therefore share a common group identifier. This group is the bulk binding update group. Both the mobile access gateway and the local mobility anchor maintain it, and the grouping logic is local to each node. So a mobility session can be identified by two bulk binding update group identifiers: one specific group created by the mobile access gateway, and another specific group created by the local mobility anchor. These bulk binding update group identifiers are exchanged as part of the initial mobility session creation. After that, the mobility entities can perform binding update operations such as lifetime extension and revocation on an entire bulk binding update group identified by the group identifier 💅.

3. Bulk Binding Update Overview 💫

3.1. Motivation

Picture a typical Proxy Mobile IPv6 domain: one local mobility anchor serves multiple mobile access gateways, and that node can host a ton of mobility sessions, typically in the order of a few millions 🤯. The more mobility sessions a local mobility anchor hosts, the more periodic binding update signaling traffic piles up.

The currently specified binding update procedure for extending the lifetimes of multiple mobility sessions is, honestly, inefficient or sub-optimal 😭. The mobile access gateway is required to send a unique binding update message for each mobility session, even when the session state hasn't changed at all. Those periodic messages eat up a big chunk of network resources at both peers, in terms of processing power and network bandwidth. There's a real chance to optimize the signaling by letting the local mobility anchor and the mobile access gateway do bulk binding update operations. This document specifies extensions to Proxy Mobile IPv6 signaling for binding update and revocation operations on a group of mobility sessions. And the best part? These extensions don't take away the existing ability to do binding operations on a single mobility session. Iconic, no notes 👑.

3.2. General Operation 🎀

Okay bestie, so this mechanism lets the mobile access gateway and the local mobility anchor do binding update and revocation operations on a whole group of mobility sessions in one go 🫶. When a mobility session gets set up, the LMA and the MAG swap their bulk binding update group identifiers for that session as part of the initial signaling. After that, both peers can run bulk operations on those groups just by putting the group identifier in their signaling messages 💅.

When a MAG sends a Proxy Binding Update after spotting a new mobile node on its access link, it can ask the LMA to assign a bulk binding update group identifier for that mobility session ✨. It does this by setting the (B) flag in the PBU to a value of (1). The MAG will also assign its own bulk binding update group identifier (or it may use the default group, ALL-SESSIONS) and pop it into the Mobile Node Group Identifier option 🧚.

If the LMA says yes, it puts the mobility session into a specific bulk binding update group (or the default ALL-SESSIONS group) and sends that identifier back in a Proxy Binding Acknowledgement. It also sets the (B) flag in the PBA to a value of (1). The identifier rides along in the Mobile Node Group Identifier option, which is described in Section 4.3 💖.

Once both sides have their identifiers, the LMA and the MAG can do binding operations on entire groups by including the group identifier in their signaling messages 👑. For example, the MAG can extend the lifetime of every session in a group with a single Proxy Binding Update carrying that identifier 🌈. The LMA can revoke every session in a group the same way, by putting the group identifier in a Proxy Binding Revocation 🔥. One important detail: when someone starts a bulk operation, the group identifier in the Mobile Node Group Identifier option is always the identifier of the local group, never the identifier of the group on the peer 🙈.

Figure 1 shows the whole flow for a group of mobile nodes (MN1, MN2, and MN3) 🦋:

           MAG                         LMA
      (1)  |                            |
 MN1-------|           (2) PBU          |
           |--------------------------->|
           |                            * (3)
           |           (4) PBA          |
           |<---------------------------|
           * (5)                        |
      (6)  |                            |
 MN2-------|                            |
           * (7)........................|
      (8)  |                            |
 MN3-------|                            |
           * (9)........................|
           |                            |
           |           (10) PBU         |
           |--------------------------->|
           |                            * (11)
           |           (12) PBA         |
           |<---------------------------|
           * (13)
           |                            |
           |           (14) BRI         |
           |<---------------------------|
           |                            * (15)
           |           (16) BRA         |
           |--------------------------->|
           * (17)                       |
           |                            |

Figure 1: Exchange of Group Identifier

Here's the play-by-play 📖:

  • (1) to (2): The MAG notices MN1 hopping onto the access link. It puts MN1 into a specific bulk binding update group, (M1), and tells the LMA about it by including that identifier in the Mobile Node Group Identifier option of the PBU 💅.
  • (3): After accepting the PBU, the LMA creates a mobility session and puts it into a specific bulk binding update group, (L1). It updates MN1's Binding Cache entry so it holds both (L1) and the identifier the MAG sent, (M1). The LMA also tells the MAG about (L1) by including it in the PBA 🎀.
  • (4) to (5): When the PBA arrives, the MAG updates the Binding Update List entry for that mobility session so it holds both (L1) and (M1). At this point, both the LMA and the MAG know MN1's bulk binding update group identifiers, assigned by the peers 🫶.
  • (6) to (9): Steps (1) through (5) happen again for MN2 and MN3. The details get skipped here. By the end of step (9), the MAG has finished signaling with the LMA. The MAG puts MN2 and MN3 into bulk binding update groups (M1) and (M2) respectively, while the LMA puts both of them into the same group, (L1) 💜.
  • Right now: The LMA has MN1, MN2, and MN3 all in group (L1). The MAG has MN1 and MN2 in group (M1) and MN3 in group (M2). Both peers can now run binding operations on their groups using the identifiers each one assigned 🌸.
  • (10) to (13): The MAG sends a Proxy Binding Update to extend the lifetime of every mobility session in group (M1). It includes (M1) in the PBU. When the LMA accepts it, the LMA extends the lifetime of both MN1 and MN2, since they're both in (M1) 🍓.
  • (14) to (17): The LMA decides to revoke every session in group (L1), so it sends a Binding Revocation Indication (BRI) carrying (L1). When the MAG accepts the BRI, it revokes MN1, MN2, and MN3's mobility sessions, since they're all part of (L1). Then it sends a Binding Revocation Acknowledgement (BRA) [RFC5846] message back 😭.

4. Message Formats ✨

This section identifies the extensions to Proxy Mobile IPv6 signaling messages that are required for supporting this specification 🧚.

4.1. Extensions to Proxy Binding Update 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 #         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|H|L|K|M|R|P|F|T|B| Reserved  |            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Extensions to Proxy Binding Update Message

Okay so there's a brand new flag, the Bulk-Binding-Update flag (B), defined in the Proxy Binding Update message from [RFC5213] 🦋. In the flags field of that message, its bit value is 0x0040 💅.

If the Bulk-Binding-Update flag (B) is set to a value of (1), it tells the local mobility anchor to turn on bulk binding update support for the mobility session linked to this message ✨. But if the (B) flag is set to a value of (0), the local mobility anchor MUST exclude that mobility session from any bulk-binding-related operations. Any binding update or binding revocation operations with bulk-specific scope just won't apply to that session 🙈.

This flag is only relevant for Proxy Mobile IPv6, so it MUST be set to the value of (0) when the (P) flag is set to a value of (0) 🌸.

Everything else in the Proxy Binding Update message, and the mobility options that can ride along in it, conforms to the appropriate specifications 🫶.

4.2. Extensions to Proxy Binding Acknowledgement 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
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   Status      |K|R|P|T|B| Res.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Sequence #            |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Extensions to Proxy Binding Acknowledgement Message

Same vibe here: the Bulk-Binding-Update flag (B) is a new flag, this time defined in the Proxy Binding Acknowledgement message from [RFC5213] 💜. Its bit value in the flags field is 0x08 🎀.

If the Bulk-Binding-Update flag (B) is set to a value of (1), it's the LMA's way of telling the mobile access gateway that bulk binding update support has been enabled for the mobility session linked to this message 👑. The value of this flag MUST be set to the value of (0) if the (B) flag in the Proxy Binding Update the MAG sent was set to a value of (0) 😭.

This flag is only relevant for Proxy Mobile IPv6, so it MUST be set to a value of (0) when the (P) flag is set to a value of (0) 🍓.

Everything else in the Proxy Binding Acknowledgement message, and the mobility options that can be carried in it, conforms to the appropriate specifications 🌸.

4.3. Mobile Node Group Identifier Option ✨

okay so this is a brand new option, the Mobile Node Group Identifier option 🎀 It's for Proxy Mobile IPv6 signaling messages that go between a local mobility anchor and a mobile access gateway. It carries the mobile node's group identifier. You can fit several instances into one message, but each one SHOULD have a different sub-type value 🫶 It's a generic option, and this spec only uses sub-type (1) 💅

Its type value is 50 🍓

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |   Length      |  Sub-type   |    Reserved     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Mobile Node Group Identifier                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Mobile Node Group Identifier Option

Type

The type is <50> 🧚

Length

This 8-bit unsigned integer tells you the length in octets of this option, not counting the type and length fields. The value for this field MUST be set to a value of (6). No exceptions, bestie 💅

Sub-type

This 8-bit field identifies the specific mobile node's group type 🦋 IANA manages this number space. The sub-type value of (1) is reserved for the Bulk Binding Update Group.

Reserved

This 8-bit field is unused for now. The value MUST be initialized to (0) by the sender and MUST be ignored by the receiver 🌸

Mobile Node Group Identifier

This 32-bit field holds the mobile node's group identifier. The value of (0) is reserved and SHOULD NOT be used 🙅‍♀️ The value of (1) ALL-SESSIONS is the default group of all mobility sessions established between a given local mobility anchor and a mobile access gateway. It's giving main character energy 👑

4.4. Status Codes

This document defines these new status code values for the Proxy Binding Acknowledgement message ✨ They were pulled from the same number space as Section 6.1.8 of [RFC6275], so they're family 🫶

INVALID_MOBILE_NODE_GROUP_IDENTIFIER: 175

Invalid group identifier value in the request 💀

5. Protocol Considerations 👑

5.1. MAG Considerations

Okay, here's the stuff that matters for the mobile access gateway when it's supporting this spec 🌈

5.1.1. Extensions to Binding Update List Entry Data Structure

The conceptual Binding Update List entry data structure that the mobile access gateway keeps, described in Section 6.1 of [RFC5213], gets extended with these REQUIRED additional fields 🎀

  • MAG-Bulk-Binding-Update-Group-Id: This is the bulk binding update group identifier assigned by this mobile access gateway for this mobility session. It's a 32-bit unsigned integer. It is not globally unique within a Proxy Mobile IPv6 domain, so other nodes can end up with the same group identifier value 🙈
  • LMA-Bulk-Binding-Update-Group-Id: This is the bulk binding update group identifier assigned by the local mobility anchor for this mobility session. It's a 32-bit unsigned integer. It comes in the Mobile Node Group Identifier option of the Proxy Binding Acknowledgement message. It is not globally unique within a Proxy Mobile IPv6 domain either, so other nodes may use the same value 💜

5.1.2. Requesting Bulk Binding Update Support for a Mobility Session

Here's how the mobile access gateway asks for bulk binding update support for a mobility session 💅

  • When sending a Proxy Binding Update message to the local mobility anchor, the mobile access gateway can choose to ask the local mobility anchor to turn on bulk binding update support for the mobility session tied to that request. When it does, the Bulk-Binding-Update flag (B) in the request MUST be set to a value of (1), and the Mobile Node Group Identifier option MUST be present. Whether to ask is a local policy call at the mobile access gateway, controlled by the configuration variable RequestBulkBindingUpdateSupportForMobilitySession 🦋
  • The mobile access gateway MUST assign a bulk binding update group identifier for the mobility session. How it does that is outside the scope of this document 🙈 The group identifier can be unique to the service card the session is hosted on, or based on other grouping considerations. When there's no group assignment, the mobile access gateway SHOULD assign the default group identifier value of (ALL-SESSIONS). The assigned group identifier value MUST be present in the Mobile Node Group Identifier option, and the sub-type value in that option MUST be set to a value of (1) (Bulk Binding Update Group) 🫶
  • If the received Proxy Binding Acknowledgement message has the status code value set to (0) (Proxy Binding Update accepted) and the Bulk-Binding-Update flag (B) set to a value of (0), in response to a Proxy Binding Update request that had the Bulk-Binding-Update flag (B) set to a value of (1), that's the local mobility anchor saying no 😭 It denied the request to enable bulk binding update support, so the mobility session isn't in any bulk binding update group. The mobile access gateway SHOULD set LMA-Bulk-Binding-Update-Group-Id and MAG-Bulk-Binding-Update-Group-Id to a value of (0) in the Binding Update List entry for that session. Furthermore, the mobility session should be excluded from any bulk binding update operations 🥀
  • If the received Proxy Binding Acknowledgement message has the status code value set to (0) (Proxy Binding Update accepted) and the Bulk-Binding-Update flag (B) in the reply is set to a value of (1), the local mobility anchor said yes ✨ It accepted the request to allow bulk binding update support for that mobility session. The Mobile Node Group Identifier option in the reply, with sub-type (1) (Bulk Binding Update Group), holds the bulk binding update group identifier the local mobility anchor assigned for that session. The mobile access gateway MUST update the LMA-Bulk-Binding-Update-Group-Id and MAG-Bulk-Binding-Update-Group-Id parameters in the Binding Update List entry for that session. However, if the received Proxy Binding Acknowledgement message has the Bulk-Binding-Update flag (B) set to a value of (1) but the Mobile Node Group Identifier option is not present, the message MUST be considered malformed and ignored 🚫
  • If, at any point, the mobile access gateway chooses to ask the local mobility anchor to disable bulk binding update support for a mobility session, it MUST send a Proxy Binding Update message with the (B) flag set to a value of (0), and the Mobile Node Group Identifier option MUST NOT be present. This message goes out as a normal binding update request for lifetime extension. Requirements from Section 6.9.1 of [RFC5213] apply. On top of that, the mobile access gateway MUST update the Binding Update List entry by setting LMA-Bulk-Binding-Update-Group-Id and MAG-Bulk-Binding-Update-Group-Id to a value of (0), and the mobility session MUST be excluded from any bulk binding update operations 🌸

5.1.3. Supporting Bulk Binding Updates ✨

Okay bestie, this part is about what the mobile access gateway (MAG) has to do when it's handling binding updates and revocations for a whole group of sessions at once 🫶

  • 💖 Bulk binding updates (extending lifetimes): when the MAG wants to extend the lifetime of every mobility session sharing the same bulk binding update group identifier, it can choose to send a bulk binding update request. It sends a Proxy Binding Update message to the local mobility anchor with the Mobile Node Group Identifier option, sub-type value (1) (Bulk Binding Update Group), and the Bulk-Binding-Update flag (B) set to a value of (0). The identifier value in the option MUST be set to the bulk binding update group identifier of the group the operation is being requested for. The message MUST NOT include any individual session identifiers, like the Mobile Node Identifier option [RFC4283], the Home Network Prefix option [RFC5213], the IPv4 Home Address Request option [RFC5844], or the GRE Key option [RFC5845]. All the considerations from Section 5.3.3 of [RFC5213] MUST be followed when sending the bulk binding update request, with the one exception being the use of the Mobile Node Group Identifier option in place of the individual session identifiers (Mobile Node Identifier option, Home Network Prefix option, GRE Key option, and IPv4 Home Address Request option). 🎀
  • 🦋 Bulk revocations: when the MAG wants binding revocation for every session sharing that group identifier, it can choose to send a bulk revocation request. It sends a Binding Revocation Indication message [RFC5846] to the local mobility anchor with the Mobile Node Group Identifier option, sub-type value (1) (Bulk Binding Update Group). The identifier value in the option MUST be set to the bulk binding update group identifier of the group the operation is being requested for. The message MUST NOT include any individual session identifiers, like the Mobile Node Identifier option [RFC4283], the Home Network Prefix option [RFC5213], the IPv4 Home Address Request option [RFC5844], or the GRE Key option [RFC5845]. All the considerations from Section 9.2 of [RFC5846] MUST be followed when sending the bulk binding update request, with the one exception being the use of the Mobile Node Group Identifier option in place of the individual session identifiers (Mobile Node Identifier option, Home Network Prefix option, GRE Key option, IPv4 Home Address Request option). 🌸
  • 👑 Receiving a bulk revocation: any time the MAG gets a Binding Revocation Indication message [RFC5846] with a Mobile Node Group Identifier option present and sub-type value (1) (Bulk Binding Update Group), that message counts as a bulk revocation request. Its scope is revoking all the mobility sessions in that bulk binding update group, specific to that local mobility anchor and identified by the group identifier in the Mobile Node Group Identifier option. ⭐
  • 🧚 Everything else about revocations: all the considerations from [RFC5846] apply when processing a binding revocation request, except that the scope of the operation now applies to a set of mobility sessions identified by the bulk binding update group identifier in the request. 💅
  • 🚫 Mixing in individual session identifiers is a no-go: if the received Binding Revocation Indication message includes the Mobile Node Identifier option [RFC4283], the Home Network Prefix option [RFC5213], the IPv4 Home Address Request option [RFC5844], or the GRE Key option [RFC5845], the mobile access gateway MUST consider this an invalid message. It MUST reject the Binding Revocation Indication message and send a Binding Revocation Acknowledgement message with the Status field set to a value of 128 (Binding Does NOT Exist). 💀

5.2. LMA Considerations 🌈

The following are the considerations for a local mobility anchor when it's supporting this specification. Let's go 😤

5.2.1. Extensions to Binding Cache Entry Data Structure 🍓

The conceptual Binding Cache entry data structure the local mobility anchor keeps, described in Section 5.1 of [RFC5213], gets extended with the following REQUIRED additional fields. 💜

  • MAG-Bulk-Binding-Update-Group-Id 🧁

This is the bulk binding update group identifier the mobile access gateway assigned for this mobility session. It's a 32-bit unsigned integer. The identifier is received in the Mobile Node Group Identifier option of the Proxy Binding Update message. It is NOT globally unique within a Proxy Mobile IPv6 domain, so the same group identifier value can be used by other nodes too. 🌍

  • LMA-Bulk-Binding-Update-Group-Id 🍒

This is the bulk binding update group identifier the local mobility anchor assigned for this mobility session. It's a 32-bit unsigned integer. It is NOT globally unique within a Proxy Mobile IPv6 domain, so the same group identifier value can be used by other nodes too. 🌸

Wait, I need to correct something before this goes any further. I wrote "It is NOT globally unique" above, but the original says "This identifier is not globally unique." That is plain prose, so the lowercase "not" should stay lowercase. Here is the corrected version of those two bullets:

  • MAG-Bulk-Binding-Update-Group-Id 🧁

This is the bulk binding update group identifier the mobile access gateway assigned for this mobility session. It's a 32-bit unsigned integer. The identifier is received in the Mobile Node Group Identifier option of the Proxy Binding Update message. This identifier is not globally unique within a Proxy Mobile IPv6 domain, so the same group identifier value can be used by other nodes too. 🌍

  • LMA-Bulk-Binding-Update-Group-Id 🍒

This is the bulk binding update group identifier the local mobility anchor assigned for this mobility session. It's a 32-bit unsigned integer. This identifier is not globally unique within a Proxy Mobile IPv6 domain, so the same group identifier value can be used by other nodes too. 🌸

5.2.2. Enabling Bulk Binding Update Support for a Mobility Session 🔥

The local mobility anchor will process a received Proxy Binding Update message as specified in [RFC5213]. However, if the (B) flag in the received Proxy Binding Update message is set to a value of (1) and it includes a Mobile Node Group Identifier option with sub-type value (1) (Bulk Binding Update Group), the following processing takes place. 🧚

  • 🫶 If the (B) flag in the received Proxy Binding Update message is set to a value of (1) and the Mobile Node Group Identifier option is present in the request, the message serves as a request to the local mobility anchor to enable bulk binding update support for that mobility session.
  • ✨ Upon successful processing and acceptance of the Proxy Binding Update, the local mobility anchor can choose to enable bulk binding update support for this mobility session. Whether to enable it is a matter of local policy, controlled by the configuration variable AcceptBulkBindingUpdateReqForMobilitySession.
  • 🔑 To enable bulk binding update support for the mobility session, the local mobility anchor MUST associate the mobility session with a specific bulk binding update group locally. How the local mobility anchor associates a given mobility session with a specific group is outside the scope of this document. The local mobility anchor can choose to assign a default bulk binding update group identifier value of (ALL-SESSIONS), meaning that all the mobility sessions from that mobile access gateway are part of that group. The local mobility anchor SHOULD update the bulk binding update group identifier values in the Binding Cache entry, LMA-Bulk-Binding-Update-Group-Id and MAG-Bulk-Binding-Update-Group-Id, to the respective values. 🎯
  • 🎀 If bulk binding update support is enabled for the mobile node's mobility session, the local mobility anchor MUST send the assigned bulk binding update group identifier as part of the Mobile Node Group Identifier option, with sub-type value (1) (Bulk Binding Update Group), in the Proxy Binding Acknowledgement message it sends to the mobile access gateway. The (B) flag in the Proxy Binding Acknowledgement message MUST be set to a value of (1). 💖
  • 🙅‍♀️ If bulk binding update support is NOT enabled for the mobility session, the local mobility anchor MUST NOT include the Mobile Node Group Identifier option with sub-type value (1) (Bulk Binding Update Group) in the Proxy Binding Acknowledgement message it sends to the mobile access gateway. The (B) flag in the Proxy Binding Acknowledgement message MUST be set to a value of (0). It's worth noting that the Mobile Node Group Identifier option is a generic option, and new sub-types may be defined by future specifications. 🌈

Hold on, I need to fix that last bullet. The original has "not enabled" in lowercase, so I'm putting it back as-is:

  • 🙅‍♀️ If bulk binding update support is not enabled for the mobility session, the local mobility anchor MUST NOT include the Mobile Node Group Identifier option with sub-type value (1) (Bulk Binding Update Group) in the Proxy Binding Acknowledgement message it sends to the mobile access gateway. The (B) flag in the Proxy Binding Acknowledgement message MUST be set to a value of (0). It's worth noting that the Mobile Node Group Identifier option is a generic option, and new sub-types may be defined by future specifications. 🌈
  • 🧸 If the received Proxy Binding Update message is not a bulk binding update request (meaning the (B) flag is set to a value of (0) and the Mobile Node Group Identifier option with sub-type value (1) (Bulk Binding Update Group) is not present), but it IS a request to extend the lifetime of an existing mobility session where bulk binding update support is already enabled, then the local mobility anchor MUST process the request as specified in [RFC5213]. However, the value of (0) in the (B) flag serves as a request for the local mobility anchor to disable bulk binding update support for that mobility session. Upon accepting the request, the local mobility anchor SHOULD set the parameters LMA-Bulk-Binding-Update-Group-Id and MAG-Bulk-Binding-Update-Group-Id in the Binding Cache entry to a value of (0), and the mobility session MUST be excluded from any bulk binding update operations. 🥺
  • 🏃‍♀️ Any time the local mobility anchor detects that the mobile node has roamed and changed its point of attachment to a new mobile access gateway, it SHOULD also update the bulk binding update group identifier of the mobility session. It should also update the existing group identifiers associated with that session. As part of sending the Proxy Binding Acknowledgement to the new mobile access gateway, it MUST include the updated group identifier in the Mobile Node Group Identifier option, with sub-type value (1). However, if the Proxy Binding Update received from the new mobile access gateway did not have the (B) flag set to a value of (1), then it MUST NOT include the mobility session in any bulk binding update group, and it MUST NOT include the Mobile Node Group Identifier option with sub-type value (1). 🛸
  • 🗑️ Any time a mobile node's mobility session is de-registered by the mobile access gateway, or the session is revoked for administrative or any other reasons, the mobility session MUST also be removed from the bulk binding update group. 🫧

5.2.3. Supporting Bulk Binding Updates ✨

okay bestie, this part is all about what the local mobility anchor (LMA) has to do for bulk binding updates and bulk revocations with group-specific scope 🫶 the vibe is "one request, whole squad of sessions" 🦋

  • okay so, any time the LMA gets a Proxy Binding Update message with the (B) flag in the request set to a value of (0) AND a Mobile Node Group Identifier option with sub-type value of (1) (Bulk Binding Update Group) 💅, the LMA MUST consider that request a bulk binding update request. The scope covers all the mobility sessions in that group, specific to that mobile access gateway, identified by the group identifier in the option 🎀. BUT if the request also has any individual session identifiers, like the Mobile Node Identifier option [RFC4283], the Home Network Prefix option [RFC5213], the IPv4 Home Address Request option [RFC5844], or the GRE Key option [RFC5845] 🙈, the LMA MUST consider that an invalid message. It MUST reject the Proxy Binding Update message and send a Proxy Binding Acknowledgement message with the Status field set to INVALID_MOBILE_NODE_GROUP_IDENTIFIER (Invalid group identifier value in the request). no cap, that's a hard no 💀
  • the LMA MUST consider the message as a request to extend the lifetime of all the mobility sessions associated with the group identifier in the Mobile Node Group Identifier option ⏰. However, if that option has sub-type value (1) (Bulk Binding Update Group) and an unknown group identifier, the LMA MUST reject the Proxy Binding Update message and send a Proxy Binding Acknowledgement message with the Status field set to INVALID_MOBILE_NODE_GROUP_IDENTIFIER (Invalid group identifier value in the request) 🥲
  • once the LMA accepts the bulk binding update request, it SHOULD extend the lifetime for all the mobility sessions in that bulk binding update group, identified by the group identifier in the Mobile Node Group Identifier option in the message 🌸. Considerations from [RFC5213] MUST be applied when extending the lifetime of a mobile node's session. The LMA MUST also send a Proxy Binding Acknowledgement message with the Status field value set to 0 (Proxy Binding Update accepted). The lifetime field MUST be set to the allocated lifetime for all the mobility sessions. The message MUST also include the Mobile Node Group Identifier option, with sub-type value (1) (Bulk Binding Update Group) and the identifier value copied from the option in the received Proxy Binding Update message ✨
  • if the LMA rejects the bulk binding update request for any administrative reason, it MUST NOT update the lifetime in the Binding Cache entries of any of the mobile nodes identified by the group identifier 🙅‍♀️. The LMA SHOULD send a Proxy Binding Acknowledgement indicating the reason for the rejection in the status code 📝
  • any time the LMA gets a Binding Revocation Indication Message [RFC5846] with a Mobile Node Group Identifier option and sub-type value (1) (Bulk Binding Update Group) 🧚, the LMA MUST consider the request a bulk revocation request. The scope covers all the mobility sessions in that bulk binding update group, specific to that mobile access gateway and identified by the group identifier in the Mobile Node Group Identifier option. BUT if the request also includes the Mobile Node Identifier option [RFC4283], the Home Network Prefix option [RFC5213], the IPv4 Home Address Request option [RFC5844], or the GRE Key option [RFC5845], the LMA MUST consider that an invalid message. It MUST reject the Binding Revocation Indication message and send a BRA message with the Status field set to a value of 128 (Binding Does NOT Exist) 🚫. All the considerations from [RFC5846] apply when processing a binding revocation request, except that the scope of the operation applies to a set of mobility sessions identified by the group identifier in the request 🍓
  • upon accepting the Binding Revocation Indication request and completing the operation, the LMA MUST send a Binding Revocation Acknowledgement message with the Status field set to a value of 0 (success) 🎉. The message MUST include the Mobile Node Group Identifier option, with the identifier value copied from the option in the received Binding Revocation Indication message 🫶

6. Protocol Configuration Variables 🎀

6.1. Local Mobility Anchor - Configuration Variables 🏰

this spec adds one new configuration variable for the LMA 🌈 the configured value is expected to survive server reboots and service restarts, so it sticks around like a good group chat 💜

AcceptBulkBindingUpdateReqForMobilitySession

this flag tells you whether or not the LMA will accept the request from the mobile access gateway to turn on bulk binding update support for the mobility session 🚪. The default value is (1), meaning it WILL accept the request. If the flag is set to (0), the LMA will deny the request ❌.

6.2. Mobile Access Gateway - Configuration Variables 🛰️

same energy on the MAG side ✨ this spec adds one new configuration variable for the mobile access gateway, and its value is expected to survive server reboots and service restarts 🔁

RequestBulkBindingUpdateSupportForMobilitySession

this flag tells you whether or not the mobile access gateway will ask the LMA to turn on bulk binding update support for the mobility session 🙋‍♀️. The default value is (1), which means the MAG sets the bulk binding update flag (B) in the Proxy Binding Update request to (1). If the flag is set to (0), the MAG sets the (B) flag in the Proxy Binding Update to (0) 🫧

7. IANA Considerations 📋

per this doc, IANA has done the following, bestie 🗂️

  • Action-1: this spec defines a new flag (B) for the Proxy Binding Update message from [RFC5213] 🏷️. The flag is described in Section 4.1. Its value has been allocated from the "Binding Update Flags" registry.
  • Action-2: this spec defines a new flag (B) for the Proxy Binding Acknowledgement message from [RFC5213] 🎟️. The flag is described in Section 4.2. Its value has been allocated from the "Binding Acknowledgement Flags" registry.
  • Action-3: this spec defines a new Mobility Header option, the Mobile Node Group Identifier option 🧩. The option is described in Section 4.3. Its Type value was assigned from the same number space as the other mobility options in [RFC6275].
  • Action-4: the Sub-type field of the Mobile Node Group Identifier option introduces a brand new number space 🌟. This number space is now managed by IANA under the registry "Mobile Node Group Identifier Type Registry". This spec reserves sub-type value (1) (Bulk Binding Update Group). New sub-type values are approved through IANA Expert Review. The value range of this field is 0 through 255, but 0 and 255 are marked as reserved. The remaining values 2-254 are available for allocation 🔢.
  • Action-5: this doc also defines a new status value, INVALID_MOBILE_NODE_GROUP_IDENTIFIER (Invalid group identifier value in the request: 175), for use in the Proxy Binding Acknowledgement message 🚨. It is described in Section 4.4. The value was assigned from the same number space as the other status codes in [RFC6275].

8. Security Considerations 🔐

okay this section is serious, so pay attention 👀

The Mobile Node Group Identifier option defined in this spec is for use in Proxy Binding Update and Proxy Binding Acknowledgement messages 🧾. It's carried like any other mobility header option and doesn't need any other special security considerations 🙂.

The bulk binding update and bulk revocation operations in this doc act on a whole group of mobility sessions 😱. If proper authorization checks aren't in place, a malicious node could hijack a mobile node's mobility session or carry out a denial-of-service attack 💀. To prevent this, the spec requires the LMA to allow only authorized mobile access gateways to perform bulk operations 🛡️.

9. Acknowledgements 🫶

the authors would like to specially thank Jouni Korhonen, Basavaraj Patil, Carlos Jesus Bernardos Cano, Dirk Von-Hugo, Pete Resnick, and Jari Arkko for reviewing this document and giving input 💖✨

10. References 📚

10.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [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.
  • [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010.
  • [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.

10.2. Informative References

  • [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
  • [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.

Authors' Addresses 💌

Fuad Abinader (editor)
Instituto Nokia de Tecnologia
Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova
Manaus, AM  69048-660
Brazil

EMail: fabinader@gmail.com


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

EMail: sgundave@cisco.com


Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA  95134
USA

EMail: kleung@cisco.com


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

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


Domagoj Premec
Unaffiliated

EMail: domagoj.premec@gmail.com
📦 where this page comes from