diff options
Diffstat (limited to 'doc/rfc/rfc5846.txt')
| -rw-r--r-- | doc/rfc/rfc5846.txt | 2187 |
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc5846.txt b/doc/rfc/rfc5846.txt new file mode 100644 index 0000000..bf02ad8 --- /dev/null +++ b/doc/rfc/rfc5846.txt @@ -0,0 +1,2187 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Muhanna +Request for Comments: 5846 M. Khalil +Category: Standards Track Ericsson +ISSN: 2070-1721 S. Gundavelli + K. Chowdhury + Cisco + P. Yegani + Juniper Networks + June 2010 + + + Binding Revocation for IPv6 Mobility + +Abstract + + This document defines a binding revocation mechanism to terminate a + mobile node's mobility session and the associated resources. This + mechanism can be used both with base Mobile IPv6 and its extensions, + such as Proxy Mobile IPv6. The mechanism allows the mobility entity + which initiates the revocation procedure to request its peer to + terminate either one, multiple or all specified Binding Cache + entries. + +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. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5846. + + + + + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 1] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as 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 are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 2] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +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 + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 3] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +1. Introduction + + In the case of Mobile IPv6 and for administrative reasons, sometimes + it becomes necessary to inform the mobile node that its registration + has been revoked and the mobile node is no longer able to receive IP + mobility service for its Home Address. A similar Mobile IPv4 + registration revocation mechanism [RFC3543] has been specified by the + IETF for providing a revocation mechanism for sessions that were + established using Mobile IPv4 registration [RFC3344]. + + This document specifies a binding revocation mechanism that can be + used to revoke a mobile node's mobility session(s). The same + mechanism can be used to revoke bindings created using Mobile IPv6 + [RFC3775] or any of its extensions, e.g., Proxy Mobile IPv6 + [RFC5213]. The proposed revocation mechanism uses a new Mobility + Header (MH) type 16 for revocation signaling that is applicable to + Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used + by any two IP mobility entities. As an example, this mechanism + allows a local mobility anchor (LMA), involved in providing IP + mobility services to a mobile node, to notify the mobile access + gateway (MAG) of the termination of that mobile node binding + registration. In another example, a mobile access gateway can use + this mechanism to notify its local mobility anchor peer with a bulk + termination of all or a subset of proxy mobile IPv6 (PMIPv6) bindings + that are registered with the local mobility anchor and currently + being served by the mobile access gateway. Any mobility entity is + allowed to revoke only the registration of those mobile node(s) + mobility sessions that are currently registered with it. + +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 + + All the general mobility related terminology and abbreviations are to + be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile + IPv6 [RFC5213] and IPv4 Support for Proxy Mobile IPv6 [RFC5844] + specifications. The following terms are used in this specification. + + + + + + + + +Muhanna, et al. Standards Track [Page 4] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + Initiator + + The mobility node that initiates 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 responds 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 + + This specification specifies a generic binding revocation mechanism + where a mobility node can communicate to the mobile node or another + mobility node the identity of the mobile node registration binding + that is being terminated. In the case when this mechanism is used + for bulk termination or multiple bindings, the identities of these + bindings are communicated to the mobile node or mobility node using + the same generic mechanism. The following subsections present the + protocol overview and applicable use cases. + +3.1. Binding Revocation Protocol + + In the case of Mobile IPv6, if the home network decides to terminate + the service of the mobile node, the home agent sends a Binding + Revocation Indication (BRI) message to the mobile node. The home + agent includes the home address (HoA) of the mobile node in the Type + 2 routing header as specified in [RFC3775] to indicate the impacted + mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) + [RFC5555], the home agent may include the IPv4 Home Address option + with the home IPv4 address assigned by the mobile node. + Additionally, if the mobile node registered multiple care-of + addresses [RFC5648], the home agent includes the Binding Identifier + (BID) option(s) in the Binding Revocation Indication message to + identify which binding is being revoked. When the mobile node + receives a Binding Revocation Indication message with its HoA + included in the Type 2 routing header, the mobile node responds by + sending a Binding Revocation Acknowledgement (BRA) message. + + Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation + procedure can be initiated by the local mobility anchor by sending a + Binding Revocation Indication message to communicate the termination + of a mobile node registration binding to the mobile access gateway. + In this case, the local mobility anchor includes the mobile node Home + Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option + + + +Muhanna, et al. Standards Track [Page 5] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + [RFC4283] to indicate to the mobility access gateway the identity of + the PMIPv6 binding that needs to be terminated. When the mobile + access gateway receives the Binding Revocation Indication message, + the mobile access gateway responds to the local mobility anchor by + sending a Binding Revocation Acknowledgement message. + + On the other hand, the mobile access gateway usually sends a de- + registration message by sending a Proxy Binding Update with a + lifetime of zero to indicate to the local mobility anchor of the + termination of the PMIPv6 mobile node binding registration. 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] in + order for the local mobility anchor to identify the mobile node + PMIPv6 binding. Additionally, in the case when the mobile access + gateway communicates a bulk termination of PMIPv6 mobility sessions, + the mobile access gateway sends a Binding Revocation Indication + message with the Global (G) bit set and includes the mobile access + gateway identity in the MN-ID option, see Section 9.2 and + Section 8.2. When the local mobility anchor receives such a Binding + Revocation Indication message, it ensures that the mobile access + gateway is authorized to send such a bulk termination message, see + Section 13, and then processes the Binding Revocation Indication + message accordingly. If the local mobility anchor processes the + Binding Revocation Indication message successfully, the local + mobility anchor responds to the mobile access gateway by sending + Binding Revocation Acknowledgement message. + + In any of the above cases, the initiator of the binding revocation + procedure, e.g., home agent, local mobility anchor, or mobile access + gateway, uses the Revocation Trigger field in the Binding Revocation + Indication message to indicate to the receiving node the reason for + initiating the revocation procedure. + +3.2. MIPv6 and DSMIP6 Use Case + + The binding revocation mechanism is applicable 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. This mechanism enables the user or the mobile + node to react to the revocation, e.g., reinstate its interrupted + Mobile IPv6 services. + + In this case, the home agent sends a Binding Revocation Indication + message to indicate to the mobile node that its current mobile IPv6 + (MIPv6) binding has been revoked and it is no longer able to 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. In the case of + + + +Muhanna, et al. Standards Track [Page 6] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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 Binding Revocation + Indication message, it sends a Binding Revocation Acknowledgement + message to the home agent. Figure 1 illustrates 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 + + In the case of 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, the home agent sends a + Binding Revocation Indication message to the mobile node with the + corresponding BID option included. If more than one of the mobile + node registered care-of addresses needs to be revoked, the home agent + includes all the corresponding BID options in the same Binding + Revocation Indication message. Figure 2 illustrates the message flow + when the home agent revokes two registered care-of addresses for the + same mobile node in a single Binding Revocation Indication message. + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 7] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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 + 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 illustrates the message flow when the home agent revokes all + registered care-of address bindings for a mobile node in a single + Binding Revocation Indication message. + +3.4. Proxy MIPv6 Use Case + + Since the mobile node does not participate in the mobility mechanism + in the case of PMIPv6, there are many scenarios where the Binding + Revocation mechanism is needed to clean resources and make sure that + the mobility entities, i.e., mobile access gateway and local mobility + anchor, are always synchronized with respect to the status of the + existing PMIPv6 bindings. The binding revocation mechanism is + generic enough that it can be used for all Proxy Mobile IPv6 + scenarios that follow the [RFC5213] and [RFC5844] specifications. + + When the mobile access gateway receives a Binding Revocation + Indication message as in Section 9.1, the mobile access gateway sends + a Binding Revocation Acknowledgement message to the local mobility + anchor following the rules described in Section 6.1.2. Similarly, if + the local mobility anchor receives a Binding Revocation Indication + message, the local mobility anchor responds to the mobile access + gateway by sending a Binding Revocation Acknowledgement message. + + + + + + + + +Muhanna, et al. Standards Track [Page 8] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation + + The local mobility anchor may send a Binding Revocation Indication + message with the appropriate revocation trigger value to the mobile + access gateway that hosts a specific PMIPv6 binding to indicate that + the mobile node binding has been terminated and the mobile access + gateway can clean up the applicable resources. When the mobile + access gateway receives a Binding Revocation Indication message, the + mobile access gateway identifies the respective binding and it sends + a Binding Revocation Acknowledgement message to the local mobility + anchor. In this case, the mobile access gateway could terminate the + IPv6 or IPv4 mobility session on the access link and notify the + mobile node as in Section 9.1. + + As an example, Figure 3, illustrates the message sequence for + revoking a mobile node binding at the source mobile access gateway + during the mobile node inter-MAG handover. During the inter-MAG + handover, the mobile node moves from the source MAG to the target + MAG. The target MAG sends a Proxy Binding Update with the new + care-of address to the local mobility anchor to update the mobile + node's point of attachment. Since the mobile node binding at the + local mobility anchor points to the source MAG and upon receiving the + Proxy Binding Update from the target MAG, the local mobility anchor + updates the MN Binding Cache entry (BCE) and sends a Proxy Binding + Acknowledgement to the target MAG. The local mobility anchor can + send a Binding Revocation Indication message with the appropriate + revocation trigger value, e.g., inter-MAG handover - different Access + Types, to the source MAG in order to clean up the applicable + resources reserved for the specified mobile node binding. The source + mobile access gateway acknowledges the Binding Revocation Indication + message by sending a Binding Revocation Acknowledgement message to + indicate the success or failure of the termination of the mobile + node's binding. + + The process identified above can also be used by the local mobility + anchor in scenarios other than the inter-MAG handover with the proper + revocation trigger value to indicate to the peer mobile access + gateway that a specific PMIPv6 binding or bindings have been revoked. + + + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 9] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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 + + In addition, the local mobility anchor can send a Binding Revocation + Indication message to indicate that all bindings that are hosted by + the peer mobile access gateway and registered with the local mobility + anchor are being revoked by setting the Global (G) bit as described + in Section 8.1. + +3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings + + The mobile access gateway sends a BRI message with the Global (G) bit + set and the Revocation Trigger field set to "Per-Peer Policy" to + indicate that all mobility bindings that are registered at the local + mobility anchor and attached to the mobile access gateway are being + revoked as in Section 9.2. When the local mobility anchor receives + this Binding Revocation Indication message from the specified mobile + access gateway, the local mobility anchor first checks if the mobile + access gateway is authorized to use global revocations, then it + responds with the appropriate status code by sending a Binding + Revocation Acknowledgement message as in Section 6.1.2. + +4. Binding Revocation Messages over IPv4 Transport Network + + In some deployments, the network between the mobile access gateway + and the local mobility anchor may only support IPv4 transport. + Another case is when a mobile node that supports client mobile IPv6 + + + +Muhanna, et al. Standards Track [Page 10] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + roams to an access network where only IPv4 addressing and transport + is supported. In this 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 the same UDP + encapsulation. The same UDP source and destination port numbers and + IPv4 addresses used for exchanging 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. For example, + the source UDP port number, the destination UDP port number, the + source IPv4 address, and the destination IPv4 address of the Binding + Revocation Indication message are set to the destination UDP port + number, the 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, see [RFC5844] and [RFC5555], respectively. + +5. Binding Revocation Message + + This section defines the Binding Revocation Message format using an + MH Type 16 as illustrated in Figure 4. The value in the Binding + Revocation Type field defines whether the Binding Revocation Message + is a Binding Revocation Indication or Binding Revocation + Acknowledgement. If the Binding Revocation Type field is set to 1, + the Binding Revocation Message is a Binding Revocation Indication as + in Section 5.1. However, if the value is 2, it is a Binding + Revocation Acknowledgement message as in 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 + + + + +Muhanna, et al. Standards Track [Page 11] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + Payload Proto + + 8-bit selector. See [RFC3775] for more details. + + Header Len + + 8-bit unsigned integer. Representing 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. + + 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. It 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 that is defined in this document for the specified + value in the Binding Revocation Type field. In this document, it + is either a Binding Revocation Indication as in Section 5.1 or + Binding Revocation Acknowledgement as in Section 5.2. + + + +Muhanna, et al. Standards Track [Page 12] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +5.1. Binding Revocation Indication Message + + The Binding Revocation Indication (BRI) message is a Binding + Revocation Message that has an MH type 16 and a Binding Revocation + Type value of 1. It is used by the initiator to inform the responder + of the identity of a specific binding or bindings for which IP + mobility service are being revoked. Binding Revocation Indication + message is sent as described in Sections 7, 8.1, and 9.2. + + When the value 1 is indicated in the Binding Revocation Type field of + the Binding Revocation Message, the format of the Binding Revocation + Message Data follows the Binding Revocation Indication message as 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 + + 8-bit unsigned integer indicating the event that triggered the + initiator to send the BRI message. The Per-MN Revocation Trigger + values are less than 128. The Per-MN Revocation Trigger is used + when the BRI message intends to revoke one or more bindings for + the same mobile node. The Global Revocation Trigger values are + greater than 128 and less than 250 and used in the BRI message + when the Global (G) bit is set for global revocation. The values + 250-255 are reserved for testing purposes only. The following + Revocation Trigger values are currently defined: + + 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 + + + +Muhanna, et al. Standards Track [Page 13] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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 + + A 16-bit unsigned integer used by the initiator to match a + returned Binding Revocation Acknowledgement with this Binding + Revocation Indication. This sequence number 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 Proxy Binding (P) bit is set by the initiator to indicate that + the revoked binding(s) is a PMIPv6 binding. + + IPv4 HoA Binding Only (V) + + The IPv4 HoA Binding Only (V) bit is set by the initiator, home + agent, or local mobility anchor to indicate to the receiving + mobility entity the termination of the IPv4 Home Address binding + only as in Sections 7 and 8.1. + + Global (G) + + The Global (G) bit is set by the initiator, LMA or MAG, 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 + + A variable-length field of such length that the complete Mobility + Header is an integer multiple of 8 octets long. This field + + + +Muhanna, et al. Standards Track [Page 14] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + contains 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. These mobility + options are used by the responder to identify the specific binding + or bindings that the initiator is requesting be revoked. + + The following options are valid in a Binding Revocation Indication: + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + o 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. + + + + + +Muhanna, et al. Standards Track [Page 15] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +5.2. Binding Revocation Acknowledgement Message + + The Binding Revocation Acknowledgement (BRA) message is a Binding + Revocation Message that has an MH type 16 and a Binding Revocation + Type value of 2. It is used to acknowledge the receipt of a Binding + Revocation Indication message described in Section 5.1. This packet + is sent as described in Section 6.1.2. + + When the value 2 is indicated in the Binding Revocation Type field of + the Binding Revocation Message, the format of the Binding Revocation + Message Data follows the Binding Revocation Acknowledgement message + as 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 8-bit unsigned integer indicating the result of processing + the Binding Revocation Indication message by the responder. + Values of the Status field less than 128 indicate that the Binding + Revocation Indication was processed successfully by the responder. + Values greater than or equal to 128 indicate that the Binding + Revocation Indication was rejected by the responder. The + following Status values are currently defined: + + 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 + + + + +Muhanna, et al. Standards Track [Page 16] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + Sequence Number + + The sequence number in the Binding Revocation Acknowledgement is + copied from the Sequence Number field in the Binding Revocation + Indication. It is used by the initiator, e.g., HA, LMA, MAG, in + matching 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 + + A variable-length field of such length that the complete Mobility + Header is an integer multiple of 8 octets long. This field + contains zero or more TLV-encoded mobility options. In the case + when the Status field is set to success, no mobility option is + required. The mobility option(s) is usually used to communicate + information of the bindings that failed the revocation procedure. + + The following mobility options are valid in a Binding Revocation + Acknowledgement: + + o Home Network Prefix option [RFC5213]. This option MAY be included + only when the (P) bit is set. + + o 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. + + + + + +Muhanna, et al. Standards Track [Page 17] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + o 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 + + The following subsections describe the details of the generic binding + revocation process as used by the different mobility entities. + +6.1. Sending Binding Revocation Message + + When sending a Binding Revocation message, the initiator constructs + the packet as it would do with any other Mobility Header with the + exception of setting the MH Type field to 16. + + The Binding Revocation Message MUST be protected using the same + underlying security association, e.g., IPsec, that is being used + between the two peers to protect the mobile node's Mobile IPv6 and + its extensions binding registration signaling. If IPsec is not used + as the underlying security mechanism to protect the binding + registration signaling, the used underlying security mechanism 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: + + o The initiator MUST set the Sequence Number field to a valid + sequence number for Binding Revocation. Since sending a Binding + Revocation Indication message is not done on a regular basis, a + 16-bit Sequence Number field is large enough to allow the + initiator to match the Binding Revocation Acknowledgement to the + associated Binding Revocation Indication using the Sequence Number + field only. + + o If the initiator is revoking a binding that was created using + proxy MIPv6 registration, the initiator MUST set the Proxy Binding + (P) bit. + + + + + + +Muhanna, et al. Standards Track [Page 18] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + o 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 set the + Revocation Trigger field to a valid value from the list of Global + Revocation Triggers. + + o 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. + + o 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 is being revoked. + +6.1.2. Sending Binding Revocation Acknowledgement + + The responder MUST send a Binding Revocation Acknowledgement message + to indicate the receipt and the status of processing of the + corresponding Binding Revocation Indication message as follows: + + o 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. + + o If the responder accepts the Binding Revocation Indication + message, the responder MUST send a successful Binding Revocation + Acknowledgement with an appropriate status code. + + o 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. + + 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: + + + + +Muhanna, et al. Standards Track [Page 19] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + o The responder MUST set the Sequence Number field by copying the + value from the Sequence Number field of the received Binding + Revocation Indication. + + o The responder MUST set the Status field to a valid value that + reflects the status of the processing of the received Binding + Revocation Indication message. + + o If the (P) bit is set in the received Binding Revocation + Indication, the responder MUST set the (P) bit in the Binding + Revocation Acknowledgement. + + o 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. + + o 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. + + o 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 receiving a Binding Revocation Message, the responder MUST + verify the Mobility Header as described in Section 9.2. of [RFC3775]. + If the packet is dropped due to failing any of the Mobility Header + test checks, the responder MUST follow the processing rules as in + Section 9.2 of [RFC3775]. If the responder does not support the + Binding Revocation Indication message and does not recognize the 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 that is being used to + protect the binding registration and Binding Revocation signaling + between the two peers, e.g., an IPsec Security Association (SA). + +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, in addition, processes the message as follows: + + + + + +Muhanna, et al. Standards Track [Page 20] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + o The responder MUST validate that the Binding Revocation Indication + is formatted as in Section 5.1. + + o If the Revocation Trigger field is set to a value that the + responder does not support, the responder SHOULD reject the + Binding Revocation Indication message using status code + "Revocation Trigger NOT Supported". + + o 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". + + o If the responder failed to identify the mobile node(s) bindings as + 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, in addition, processes the message and + examines the Status field as follows: + + o 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 the sequence number does not match a sequence + number of any of the outstanding Binding Revocation Indication + messages, the initiator MUST silently discard the message but MAY + log the event. + + o 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. + + o 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 is based on + the initiator local policy how to handle the mobile node binding. + The initiator MAY log the appropriate event to reflect the + received status. + + + + + + +Muhanna, et al. Standards Track [Page 21] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +6.3. Retransmission of Binding Revocation Indication + + If the initiator does not receive a Binding Revocation + Acknowledgement in response to the outstanding Binding Revocation + Indication before the InitMINDelayBRIs timer expires, the initiator, + e.g., 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 in which the timeout period is doubled upon each + retransmission, until either the initiator receives a response or the + timeout period reaches the value MAX_BRACK_TIMEOUT. The initiator + MAY continue to send these messages at this slower rate up to the + BRIMaxRetriesNumber. + + If the initiator does not receive a Binding Revocation + Acknowledgement message after the BRIMaxRetriesNumber of 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 + + To terminate a mobile node registration and its current binding with + the home agent, the home agent sends a packet to the mobile node + containing a Binding Revocation Indication, with the packet + constructed as follows: + + o The Revocation Trigger field MUST be set to indicate to the mobile + node the reason for revoking its IP mobility binding with the home + agent. The Revocation Trigger may be used by the mobile node to + take further steps if necessary. + + o The Binding Revocation Indication MUST be sent using a Type 2 + routing header that contains the mobile node's registered IPv6 + home address for the binding being revoked. + + o The care-of address for the binding MUST be used as the + destination address in the packet's IPv6 header. + + o If the home agent needs to only revoke the mobile node's IPv4 home + address binding, the home agent MUST set the IPv4 HoA Binding Only + (V) bit and MUST include the mobile node's registered IPv4 home + address that is being revoked in the IPv4 Home Address option. + + When the home agent sends a Binding Revocation Indication to the + mobile node, the home agent sets a flag in the mobile node BCE to + indicate that revocation is in progress and starts the + + + +Muhanna, et al. Standards Track [Page 22] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + InitMINDelayBRIs timer. The home agent maintains the mobile node BCE + in this state until it receives a Binding Revocation Acknowledgement + or retransmits the Binding Revocation Indication message as described + in Section 6.3. + + In a race condition case, the home agent may receive a Binding Update + from the mobile node while the mobile node's BCE has the revocation + in progress flag set, the home agent SHOULD handle this case based on + the reason for sending the Binding Revocation Indication message and + its local policy. In this case, if the home agent accepts the + Binding Update, it needs to update the mobile node BCE accordingly, + e.g., removing the revocation in progress flag. + + When the home agent needs to revoke one or more of a mobile node + bindings that were created using multiple care-of address + registrations as in [RFC5648], the home agent MUST include all the + related BID mobility options that identify these bindings in the + Binding Revocation Indication message. In the case when the home + agent needs to revoke all of the mobile node bindings, the home agent + SHOULD NOT include any of the BID mobility options. + + When the home agent receives a packet carrying a valid Binding + Revocation Acknowledgement message, the home agent follows + Section 6.2 in processing this message. + +8. Local Mobility Anchor Operation + +8.1. Sending Binding Revocation Indication + + To terminate a mobile node PMIPv6 registration and its current + binding with the local mobility anchor, the local mobility anchor + sends a packet to the mobile access gateway containing a Binding + Revocation Indication message following the procedure in Section 6.1 + and the following rules: + + o The Proxy Binding (P) bit MUST be set to indicate that the binding + being revoked is a PMIPv6 binding. + + o The Revocation Trigger field MUST be set to indicate to the mobile + access gateway the reason for removing the specified mobile node + PMIPv6 binding at the local mobility anchor. The Revocation + Trigger may be used by the mobile access gateway to learn the + mobile node's latest movement. + + o The packet MUST contain the Mobile Node Identifier (MN-ID) option, + which contains the mobile node's Network Access Identifier (NAI) + that was used in the Proxy Binding Update during the mobile node + registration. + + + +Muhanna, et al. Standards Track [Page 23] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + o 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 to + uniquely identify the mobile node binding(s) that is being + revoked, e.g., at least one Home Network Prefix option that + contains the mobile node's registered Home Network Prefix (HNP) + for the binding being revoked. + + o In the case of 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" to request the mobile access + gateway to remove all Per-Peer bindings that are registered with + the local mobility anchor and this mobile access gateway. + + o The proxy care-of address for the binding MUST be used as the + destination address in the packet's IPv6 header. However, in the + case when 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 receiving 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, the local + mobility anchor sets a flag in the mobile node proxy BCE to indicate + that revocation is in progress and starts the InitMINDelayBRIs timer. + The local mobility anchor SHOULD maintain the mobile node proxy BCE + in this state until it receives a Binding Revocation Acknowledgement + or the BRIMaxRetransmitNumber is reached. In the case when the local + mobility anchor sets the Revocation Trigger field to a value that + indicates inter-MAG handover, the local mobility anchor 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 case, the local mobility anchor may receive a + Proxy Binding Update from the mobile access gateway while the mobile + node's proxy BCE has the revocation in progress flag set. The local + mobility anchor should handle this case based on the reason for + sending the Binding Revocation Indication message and its local + + + + + +Muhanna, et al. Standards Track [Page 24] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + policy. In this case, if the local mobility anchor accepts the Proxy + Binding Update, it needs to update the mobile node proxy BCE + accordingly, e.g., removing the revocation in progress flag. + + When the local mobility anchor needs to revoke all the mobile node + proxy BCEs that are registered with the local mobility anchor and the + mobile access gateway peer, it MUST set the Global (G) bit and set + the value of 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 the + local mobility anchor and the mobile access gateway peer, the local + mobility anchor MUST set the Global (G) bit and set the value of the + Revocation Trigger field to "Revoking Mobility Node Local Policy". + In this case, the local mobility anchor MUST include a mobility + option in the Binding Revocation Indication that is shared among all + the impacted mobile nodes BCEs, e.g., the mobile node identifier + option, MN-ID option, with a subtype value of 1. In this case, the + NAI value in the MN-ID MUST follow the format where the content after + the "@" character defines the realm that is shared amongst all of the + impacted mobile nodes proxy BCEs. As an 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 nodes proxy BCEs that belong to a specific realm and are + registered with the local mobility anchor and the mobile access + gateway, the local mobility anchor MUST set the Global (G) bit and + set the value of the Revocation Trigger field to "Revoking Mobility + Node Local Policy". In this case, the local mobility anchor 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 indicate to the mobile access gateway to remove all + bindings of the specified mobile node NAI in the MN-ID option. + + + +Muhanna, et al. Standards Track [Page 25] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + According to the Proxy Mobile IPv6 specification [RFC5213], if the + local mobility anchor receives a Proxy Binding Update message from a + new mobile access gateway for extending the binding lifetime of the + only BCE of this mobile node with the Handoff Indicator value set to + "Handoff state unknown (4)", the local mobility anchor waits a period + of 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 a de-registration + message is not received, the local mobility anchor considers the + received Proxy Binding Update message as a request for a new BCE and + if processed successfully, the local mobility anchor 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 as described in this document, it SHOULD proactively send a + Binding Revocation Indication message to the previous mobile access + gateway instead of waiting for a de-registration from the previous + mobile access gateway. In the 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 + message with the Revocation Trigger field set to "Inter-MAG Handover + - Unknown" and while waiting for a response, Binding Revocation + Acknowledgement, the following are possible conditions that the local + mobility anchor MUST handle as specified below: + + o If the local mobility anchor receives a successful Binding + Revocation Acknowledgement message or a de-registration message + from the previous mobile access gateway, the local mobility anchor + MUST update the mobile node BCE as if it received a de- + registration message as described in [RFC5213]. + + o If the local mobility anchor receives a Binding Revocation + Acknowledgement message with the Status field set to "Revocation + Failed - MN is Attached", the local mobility anchor 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]. + + o 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, the local mobility anchor 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 + + + +Muhanna, et al. Standards Track [Page 26] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + anchor SHOULD use the recommended number of retransmissions for + the Binding Revocation Indication message as described in + Section 11 to avoid delaying the creation of 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 where both of the IPv4 proxy HoA + (pHoA) and 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 maintaining 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 + the mobile node IPv4 proxy HoA only, it MUST send a Binding + Revocation Indication message following the procedure in Section 6.1 + and the following rules: + + o 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. + + o 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. + + o The mobile node Home Network Prefix option MUST NOT be included. + + o The Revocation Trigger field MUST be set to an appropriate value, + e.g., "User Initiated Session(s) Termination". + +8.2. Receiving Binding Revocation Indication + + When the local mobility anchor receives a packet carrying a Binding + Revocation Indication that was successfully processed as in + Section 6.2, the local mobility anchor processes the message as + follows: + + o If the (P) bit is set, the local mobility anchor MUST validate + that all impacted bindings have the proxy binding flag set. + + o 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 + + + + +Muhanna, et al. Standards Track [Page 27] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + Binding Revocation Indication message successfully, it MUST accept + the Binding Revocation Indication message using the status code + "success". + + o 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". + + o 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". + + o 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. + + o 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. + + + + + + +Muhanna, et al. Standards Track [Page 28] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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 + + When the mobile access gateway receives a packet carrying a Binding + Revocation Indication that was successfully processed as in + Section 6.2, the mobile access gateway processes the message as + follows: + + o 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". + + o 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 + + + +Muhanna, et al. Standards Track [Page 29] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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". + + o 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". + + o 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". + + o 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". + + + +Muhanna, et al. Standards Track [Page 30] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + o 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 + + The mobile access gateway could send a Binding Revocation Indication + message to indicate the termination of multiple mobile node bindings, + e.g., when using the global revocation with the Global (G) bit set. + In this case, when an event occurs that requires the mobile access + gateway to inform the local mobility anchor peer to terminate all + mobile node bindings that are registered at the local mobility anchor + and the mobile access gateway, the mobile access gateway sends a + Binding Revocation Indication message following the procedure in + Section 6.1 and the following: + + o The Proxy Binding (P) bit MUST be set to indicate that the + binding(s) being revoked is a PMIPv6 binding. + + o 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 + + + +Muhanna, et al. Standards Track [Page 31] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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. + + o 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. + +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: + + o 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. + + o 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". + + o 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 + + + +Muhanna, et al. Standards Track [Page 32] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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". + + o 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". + + o 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". + + o 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 + + + +Muhanna, et al. Standards Track [Page 33] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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: + + + +Muhanna, et al. Standards Track [Page 34] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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 + + + +Muhanna, et al. Standards Track [Page 35] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + 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 + + This specification allows the mobility node that initiates the + binding revocation procedure to revoke a mobility session(s) that is + currently registered with it. It is NOT allowed for any mobility + node to revoke a mobile node mobility session that is not registered + with this mobility node. + + The binding revocation protocol described in this specification uses + the same security association between the mobile node and the home + agent or the mobile access gateway and the local mobility anchor that + is being used to exchange the MIPv6 or PMIPv6 Binding Update and + Binding Acknowledgement signaling. If IPsec is used, the traffic + selectors associated with 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 + the traffic selectors of the SPD entry in order to reuse the SA + protecting the Binding Update and Binding Acknowledgement (instead of + creating new ones) ensures that those SAs will be up and running when + the revoking entity needs to send a binding revocation signaling + message. + + On the other hand, if IPsec is not used as the underlying security + mechanism to protect the Mobile IPv6 and its extensions binding + registration signaling, the used underlying security mechanism MUST + provide protection against all identified security threats as + described under "Security Considerations" in [RFC3775] and [RFC5213]. + + Since some mobility entities, e.g., local mobility anchor and mobile + access gateway, are allowed to send and receive Binding Revocation + Indications and Binding Revocation Acknowledgements for different + cases, when IPsec is used to secure signaling between the local + mobility anchor and mobile access gateway, it prevents any of them + from processing a Binding Revocation Message that was not constructed + by an authorized party. + + The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to + restrict the creation and manipulation of proxy bindings to + specifically authorized mobile access gateways. Therefore, the + mobile access gateway that is authorized to create or manipulate the + mobile node proxy BCE is also authorized to revoke such mobile node + registration by sending a de-registration with lifetime of zero. + + + +Muhanna, et al. Standards Track [Page 36] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + + However, since bulk termination using Binding Revocation Indication + with the Global (G) bit set and the Revocation Trigger field set to + "Per-Peer Policy" impacts all mobility sessions that are registered + with the mobile access gateway and its local mobility anchor peer, + the local mobility anchor MUST be locally configurable to authorize + such specific functionality. Additional mechanisms, such as a policy + store or Authentication, Authorization, and Accounting (AAA) may be + employed, but these are outside the scope of this specification. + +14. Acknowledgements + + The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- + Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay + Devarapalli, and Joel Hortelius for their review and comments of this + document and all colleagues who have supported the advancement of + this effort. + + Also, we would like to thank Jari Arkko, Ben Campbell, Pasi Eronen, + Ralph Droms, Alexey Melnikov, Tim Polk, Adrian Farrel, and Robert + Sparks for their reviews of this document as part of the IESG review + process. + +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. + + + + + + +Muhanna, et al. Standards Track [Page 37] + +RFC 5846 Binding Revocation for IPv6 Mobility June 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Muhanna, et al. Standards Track [Page 38] + +RFC 5846 Binding Revocation for IPv6 Mobility June 2010 + + +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 + + + + + + +Muhanna, et al. Standards Track [Page 39] + |