idnits 2.17.1 draft-ietf-mext-binding-revocation-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2009) is 5430 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-10 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-12 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Muhanna 3 Internet-Draft M. Khalil 4 Intended status: Standards Track Nortel 5 Expires: December 16, 2009 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Starent Networks 9 P. Yegani 10 Juniper Networks 11 June 14, 2009 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-07.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 16, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document defines a binding revocation mechanism to terminate a 53 mobile node's mobility session and the associated resources. These 54 semantics are generic enough and can be used by mobility entities in 55 the case of Mobile IPv6 and its extensions. This mechanism allows 56 the mobility entity which initiates the revocation procedure to 57 request its corresponding one to terminate either one, multiple or 58 all specified binding cache entries. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 64 2.1. Conventions used in this document . . . . . . . . . . . . 4 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 67 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 68 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6 69 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 70 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 71 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 72 Revocation . . . . . . . . . . . . . . . . . . . . . . 9 73 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10 74 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Binding Revocation Messages over IPv4 Transport Network . . . 11 76 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11 77 6.1. Binding Revocation Indication Message . . . . . . . . . . 12 78 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 16 79 7. Binding Revocation Process Operation . . . . . . . . . . . . . 18 80 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 18 81 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 19 82 7.3. Retransmission of Binding Revocation Indication . . . . . 20 83 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 20 84 8.1. Sending Binding Revocation Indication . . . . . . . . . . 20 85 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 22 86 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 22 87 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 22 88 9.1.1. Sending Binding Revocation Indication . . . . . . . . 22 89 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 26 90 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 27 91 9.2.1. Receiving Binding Revocation Indication . . . . . . . 27 92 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 28 93 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 29 94 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 29 95 10.1.1. Receiving Binding Revocation Indication . . . . . . . 29 96 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 31 98 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 31 99 10.2.1. Sending Binding Revocation Indication . . . . . . . . 32 100 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 33 101 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 33 102 11.1. Receiving Binding Revocation Indication . . . . . . . . . 33 103 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 35 104 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 35 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 106 14. Security Considerations . . . . . . . . . . . . . . . . . . . 37 107 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 108 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 109 16.1. Normative References . . . . . . . . . . . . . . . . . . . 38 110 16.2. Informative References . . . . . . . . . . . . . . . . . . 38 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 113 1. Introduction 115 In the case of Mobile IPv6 and for administrative reason, sometimes 116 it becomes necessary to inform the mobile node that its registration 117 has been revoked and the mobile node is no longer able to receive IP 118 mobility service using its Home Address. A similar Mobile IPv4 119 registration revocation mechanism [RFC3543] has been specified by 120 IETF for providing a revocation mechanism for sessions that were 121 established using Mobile IPv4 registration [RFC3344]. 123 This document specifies a binding revocation mechanism that can be 124 used to revoke a mobile node's mobility session(s). The same 125 mechanism can be used to revoke bindings created using Mobile IPv6 126 [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 127 [RFC5213]. The proposed revocation mechanism uses a new MH type 128 for revocation signaling which is applicable to Mobile 129 IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any 130 two IP mobility entities. As an example, this mechanism allows a 131 local mobility anchor (LMA), involved in providing IP mobility 132 services to a mobile node, to notify the mobile access gateway (MAG) 133 of the termination of a mobile node binding registration. In another 134 example, a mobile access gateway can use this mechanism to notify its 135 local mobility anchor peer with a bulk termination of all or a subset 136 of proxy mobile IPv6 (PMIPv6) bindings that are registered with the 137 local mobility anchor and currently being served by the mobile access 138 gateway. 140 2. Conventions & Terminology 142 2.1. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2.2. Terminology 150 All the general mobility related terminology and abbreviations are to 151 be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile 152 IPv6 [RFC5213] specifications. 154 3. Binding Revocation Protocol and Use Cases Overview 156 This specification specifies a generic binding revocation mechanism 157 where a mobility node can communicate to the mobile node or another 158 mobility node the identity of the the mobile node registration 159 binding that is being terminated. In the case when this mechanism is 160 used for bulk termination or multiple bindings, the identities of 161 these bindings are communicated to the mobile node or mobility node 162 using the same generic mechanism. The following subsections describe 163 the protocol overview and applicable use cases. 165 3.1. Binding Revocation Protocol 167 In the case of Mobile IPv6, if the home network decides to terminate 168 the service of the mobile node, the home agent sends a Binding 169 Revocation Indication (BRI) message to the mobile node. The home 170 agent includes the home address (HoA) of the mobile node in the Type 171 2 routing header as specified in [RFC3775] to indicate the impacted 172 mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) 173 [RFC5555], the home agent may include the IPv4 Home Address option 174 with the mobile node assigned home IPv4 address. Additionally, if 175 the mobile node registered multiple care-of addresses [ID-MCoA], the 176 home agent includes the Binding Identifier (BID) option(s) in the 177 Binding Revocation Indication message to identify which binding is 178 being revoked. When the mobile node receives a Binding Revocation 179 Indication message with its HoA included in the Type 2 routing header 180 and the Acknowledge (A) bit is set, the mobile node responds by 181 sending a Binding Revocation Acknowledgement (BRA) message. 183 Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation 184 procedure can be initiated by the local mobility anchor by sending a 185 Binding Revocation Indication message to communicate the termination 186 of a mobile node registration binding to the mobile access gateway. 187 In this case, the local mobility anchor includes the mobile node Home 188 Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option 189 [RFC4283] to indicate to the mobility access gateway the identity of 190 the PMIPv6 binding that needs to be terminated. When the mobile 191 access gateway receives the Binding Revocation Indication message 192 with the (A) bit set, the mobile access gateway responds to the local 193 mobility anchor by sending a Binding Revocation Acknowledgement 194 message. 196 On the other hand, the mobile access gateway usually sends a de- 197 registration message by sending a Proxy Binding Update with a 198 lifetime of zero to indicate to the local mobility anchor of the 199 termination of the PMIPv6 mobile node binding registration. In this 200 case, the mobile access gateway includes the MN-HNP option, the MN-ID 201 option and all other required mobility options as per [RFC5213] in 202 order for the local mobility anchor to identify the mobile node 203 PMIPv6 binding. Additionally, in the case when the mobile access 204 gateway communicates a bulk termination of PMIPv6 mobility sessions, 205 the mobile access gateway sends a Binding Revocation Indication 206 message with the (G) and (A) bits set and includes the mobile access 207 gateway identity in the MN-ID option. When the local mobility anchor 208 receives such Binding Revocation Indication message, it ensures that 209 the mobile access gateway is authorized to send such bulk termination 210 message and then processes the Binding Revocation Indication message 211 accordingly. If the local mobility anchor processes the Binding 212 Revocation Indication message successfully, the local mobility anchor 213 responds to the mobile access gateway by sending Binding Revocation 214 Acknowledgement message. 216 In any of the above cases, the initiator of the binding revocation 217 procedure, e.g., home agent, local mobility anchor, mobile access 218 gateway, uses the Revocation Trigger field in the Binding Revocation 219 Indication message to indicate to the receiving node the reason for 220 initiating the revocation procedure. 222 3.2. MIPv6 and DSMIP6 Use Case 224 Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 225 session(s) when the home agent needs to inform the mobile node that 226 its binding registration has been revoked, e.g. for an administrative 227 reason. This mechanism enables the user to react to the revocation, 228 e.g., reinstate its interrupted Mobile IPv6 services. 230 In this case, the home agent sends a Binding Revocation Indication 231 message to indicate to the mobile node that its current mobile IPv6 232 (MIPv6) binding has been revoked and it no longer able to receive IP 233 mobility service. The home agent includes the HoA in Type 2 routing 234 header as used in [RFC3775] and sets the Revocation Trigger field to 235 a proper value, e.g., Administrative Reason. In the case of DSMIPv6 236 session, the home agent may additionally include the mobile node 237 assigned IPv4 Home Address in the IPv4 Home Address option. When the 238 mobile node receives the Binding Revocation Indication message, it 239 sends a Binding Revocation Acknowledgement message as described in 240 Section 11.2 to the home agent. Figure 1 illustrates the message 241 sequencing when home agent revokes a mobile node binding 242 registration. 244 MN HA 245 | | 246 | HoA in Type 2 Hdr | 247 |<<<------------... + ...-----------------| 248 | BRI [seq.#, A bit, Revocation Trigger] | 249 | | 250 | | 251 | BRA (HoA in Dest. Option)[seq.#, Status] | 252 |---------------------------------------->>>| 253 | | 254 | | 256 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 258 3.3. Multi-Care of Addresses (Monami6) Use Case 260 In the case of multiple care-of addresses registration [ID-MCoA], the 261 home agent maintains different binding for each pair of care-of 262 address and home address. These bindings are also indexed and 263 identified during the mobile node registration using a BID mobility 264 option. The HA may revoke one or multiple bindings for the same 265 mobile node home address. 267 If the home agent revokes a single binding for a mobile node with 268 multiple care-of addresses registration, the home agent sends a 269 Binding Revocation Indication message to the mobile node with the 270 corresponding BID option included. If more than one of the mobile 271 node registered care-of addresses need to be revoked, the home agent 272 includes all the corresponding BID options in the same Binding 273 Revocation Indication message. Figure 2 illustrates the message flow 274 when the home agent revokes two registered Care-of addresses for the 275 same mobile node in a single Binding Revocation Indication message. 277 HA Binding Cache 278 ================ 279 MN-BID1 [CoA1+HoA] 280 MN HA MN-BID2 [CoA2+HoA] 281 | | MN-BID3 [CoA3+HoA] 282 | | MN-BID4 [CoA4+HoA] 283 | HoA in Type 2 Hdr | 284 |<<<<-------------- + ---------------------| 285 | BRI [seq.#, A bit, R. Trigger, BID1, BID4] | 286 | | 287 | | 288 | BRA (HoA in Dest. Option) [seq.#, Status] | 289 |---------------------------------------->>>>| 290 | | 291 | | 293 Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings 295 Additionally, the home agent may revoke all of the mobile node 296 registered bindings, by sending a BRI message without including any 297 BID options while the HoA is included in the Type 2 routing header. 298 Figure 1 illustrates the message flow when the home agent revokes all 299 registered Care-of addresses bindings for a mobile node in a single 300 Binding Revocation Indication message. 302 3.4. Proxy MIPv6 Use Case 304 Since the mobile node does not participate in the mobility mechanism 305 in the case of PMIPv6, there are many scenarios where Binding 306 Revocation mechanism is needed to clean resources and make sure that 307 the mobility entities, i.e., mobile access gateway and local mobility 308 anchor, are always synchronized with respect to the status of the 309 existing PMIPv6 bindings. The binding revocation mechanism is 310 generic enough that can be used for all Proxy Mobile IPv6 scenarios 311 that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. 313 When the mobile access gateway receives a Binding Revocation 314 Indication message as in Section 10.1.1, the mobile access gateway 315 sends a Binding Revocation Acknowledgement message to the local 316 mobility anchor following the rules described in Section 10.1.2. 317 Similarly, if the local mobility anchor receives a Binding Revocation 318 Indication message with the (A) bit is set, the local mobility anchor 319 responds to the mobile access gateway by sending a Binding Revocation 320 Acknowledgement message. 322 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation 324 The local mobility anchor may send a Binding Revocation Indication 325 message to the mobile access gateway, hosting a specific PMIPv6 326 binding, with the appropriate value in the revocation trigger field 327 to indicate that the mobile node binding has been terminated and the 328 mobile access gateway can clean up the applicable resources. When 329 the mobile access gateway receives a Binding Revocation Indication 330 message, the mobile access gateway identifies the respected binding 331 and if the (A) bit was set in the received Binding Revocation 332 Indication message, it sends a Binding Revocation Acknowledgement 333 message to the local mobility anchor. In this case, the mobile 334 access gateway could send a Router Advertisement message to the 335 mobile node with the home network prefix valid lifetime set to zero. 337 As an example, Figure 3, illustrates the message sequence for 338 revoking a mobile node binding at the source mobile access gateway 339 during the mobile node inter-MAG handover. During the inter-MAG 340 handover, the mobile node moves from the source MAG to the target 341 MAG. The target MAG sends a Proxy Binding Update with the new care- 342 of-address to the local mobility anchor to update the mobile node's 343 point of attachment. Since the mobile node binding at the local 344 mobility anchor points to the source MAG and upon receiving the Proxy 345 Binding Update from the target MAG, the local mobility anchor updates 346 the MN BCE and send a Proxy Binding Acknowledgement to the target 347 MAG. The local mobility anchor can send a Binding Revocation 348 Indication message with the appropriate revocation trigger value, 349 e.g. inter-MAG handover - different Access Types, to the source MAG 350 in order to clean up the applicable resources reserved for the 351 specified mobile node binding. The mobile access gateway 352 acknowledges the Binding Revocation Indication message by sending a 353 Binding Revocation Acknowledgement message to indicate the success or 354 failure of the termination of the mobile node's binding. 356 The process identified above can also be used by the local mobility 357 anchor in scenarios other than the inter-MAG handover with the proper 358 revocation trigger value to indicate to the peer mobile access 359 gateway that a specific PMIPv6 binding or bindings have been revoked. 361 oldMAG newMAG LMA 362 | | | 363 | | PBU | 364 | |--------------------------->| 365 | | PBU triggers 366 | | BRI Msg to oldMAG 367 | | | 368 | | PBA | 369 | |<---------------------------| 370 | | | 371 | | | 372 | BRI [seq.#, R. Trigger, P, A bits, NAI] | 373 |<-----------------------------------------| 374 | | | 375 | | | 376 | | | 377 | | | 378 | BRA [seq.#, Status, P bit] | 379 |----------------------------------------->| 380 | | | 381 | | | 383 Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover 385 In addition, the local mobility anchor can send a Binding Revocation 386 Indication message to indicate that all bindings which are hosted by 387 the peer mobile access gateway and registered with the local mobility 388 anchor are being revoked by setting the (G) bit as described in 389 Section 9.1.1. 391 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 393 The mobile access gateway sends a BRI message with the (G) bit is set 394 to indicate that all mobility bindings which are registered at the 395 local mobility anchor and attached to the mobile access gateway are 396 being revoked as in Section 10.2.1. When the local mobility anchor 397 receives a Binding Revocation Indication message with the (G) bit is 398 set from a specified mobile access gateway, the local mobility anchor 399 first checks if the mobile access gateway is authorized to use global 400 revocations and then responds with the appropriate status code by 401 sending a Binding Revocation Acknowledgement message as in 402 Section 9.2.2. 404 4. Security Model 406 The binding revocation protocol described here uses the same security 407 association between the mobile node and the home agent or the mobile 408 access gateway and the local mobility anchor that has been used to 409 exchange the corresponding MIPv6 or PMIPv6 Binding Update and Binding 410 Acknowledgement when the mobile node binding was created. If IPsec 411 is used, the traffic selectors associated with the SPD entry 412 protecting the Binding Update and Binding Acknowledgement MUST be 413 extended to include Binding Revocation Signaling MH type . 414 Extending the traffic selectors of the SPD entry in order to reuse 415 the SA protecting Binding Update and Binding Acknowledgement (instead 416 of creating new ones) ensures that those SA will be up and running 417 when the revoking entity needs to send a binding revocation signaling 418 message. 420 Additionally, in the case when the local mobility anchor receives a 421 Binding Revocation Indication which indicates a bulk termination 422 where the (G) bit is set and the Revocation Trigger field is set to 423 "Per-Peer Policy", the local mobility anchor MUST verify that the 424 mobile access gateway sending the binding revocation indication 425 message is authorized to invoke global revocation. 427 5. Binding Revocation Messages over IPv4 Transport Network 429 In some deployments, the network between the mobile access gateway 430 and the local mobility anchor may only support IPv4 transport. In 431 this case, the Binding Revocation messages (BRI and BRA) are tunneled 432 over IPv4. If the Proxy Binding Update and Proxy Binding 433 Acknowledgment messages are sent using UDP encapsulation to traverse 434 NATs, then the Binding Revocation messages are sent using the same 435 UDP encapsulation. The same UDP port that was used for exchanging 436 the Proxy Binding Update and Proxy Binding Acknowledgement messages 437 will also be used when transporting Binding Revocation messages over 438 IPv4 using UDP encapsulation. In other words, the destination UDP 439 port of the Binding Revocation Indication message MUST be set to the 440 source UDP port of the latest successfully processed Proxy Binding 441 Update message which is already saved in the mobile node BCE. For 442 more details on tunneling Proxy Mobile IPv6 signaling messages over 443 IPv4, see [ID-PMIP6-IPv4]. 445 6. Binding Revocation Message 447 This section defines the Binding Revocation Message format using a MH 448 Type as illustrated in Figure 4. The value in the Binding 449 Revocation Type field defines whether the Binding Revocation message 450 is a Binding Revocation Indication or Binding Revocation 451 Acknowledgement. If the Binding Revocation type field is set to 1, 452 the Binding Revocation Message is a Binding Revocation Indication as 453 in Section 6.1. However, if the value is 2, it is a Binding 454 Revocation Acknowledgement message as in Section 6.2. 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Payload Proto | Header Len | MH Type | Reserved | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Checksum | B.R. Type | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 463 | | 464 . Binding Revocation Message Data . 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 4: Binding Revocation Message 470 Binding Revocation Type 472 8-bit unsigned integer. It defines the type of Binding Revocation 473 Message. It can be assigned one of the following values: 475 0 Reserved 476 1 Binding Revocation Indication Message 477 2 Binding Revocation Acknowledgement Message 478 All other values are reserved 480 Binding Revocation Message Data 482 The Binding Revocation Message Data follows the Binding Revocation 483 Message format that is defined in this document for the specified 484 value in the Binding Revocation Type field. In this 485 specification, it is either a Binding Revocation Indication as in 486 Section 6.1 or Binding Revocation Acknowledgement as in 487 Section 6.2. 489 6.1. Binding Revocation Indication Message 491 The Binding Revocation Indication (BRI) message is a Binding 492 Revocation Message which has a MH type and a Binding 493 Revocation Type value of 1. It is used by the revoking mobility node 494 to inform the receiving mobility entity of the identity of a specific 495 binding or bindings which IP mobility service have been revoked. 496 Binding Revocation Indication message is sent as described in 497 Section 8.1, Section 9.1.1, and Section 10.2.1. 499 When the value 1 is indicated in the B. R. type field of the Binding 500 Revocation Message, the format of the Binding Revocation Message Data 501 follows the Binding Revocation Indication message as in Figure 5 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | B.R. Type = 1 | R. Trigger | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Sequence # |A|P|V|G| Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | | 511 . . 512 . Mobility options . 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 5: Binding Revocation Indication Message 518 Revocation Trigger 520 8-bit unsigned integer indicating the event which triggered the 521 revoking node to send the BRI message. The Reserved and Per-MN 522 Revocation Triggers value are less than 128 except the reserved 523 values 250-255. The per-MN revocation triggers is used when the 524 BRI message intends to revoke one or more bindings for the same 525 mobile node. The Global Revocation Trigger values are greater 526 than 128 and less than 250 and used in the BRI message with the 527 (G) bit set for global revocation. The following Revocation 528 Trigger values are currently defined: 530 Reserved and Per-MN Revocation Trigger: 531 0 Reserved 532 1 Unspecified 533 2 Administrative Reason 534 3 Inter-MAG Handover - same Access Type 535 4 Inter-MAG Handover - different Access Type 536 5 Inter-MAG Handover - Unknown 537 6 User Initiated Session(s) Termination 538 7 Access Network Session(s) Termination 539 8 Possible Out-of Sync BCE State 540 250-255 Reserved For Testing Purposes only 541 All other values are Reserved 543 Global Revocation Trigger: 544 128 Per-Peer Policy 545 129 Revoking Mobility Node Local Policy 547 Sequence # 549 A 16-bit unsigned integer used by the sending mobility node to 550 match a returned Binding Revocation Acknowledgement with this 551 Binding Revocation Indication. It could be a random number. 553 Acknowledge (A) 555 The Acknowledge (A) bit is set by the sending mobility node, e.g. 556 LMA, HA, or MAG, to request a Binding Revocation Acknowledgement 557 be returned upon receipt of the Binding Revocation Indication as 558 in Section 8.1, Section 9.1.1, and Section 10.2.1. 560 Proxy Binding (P) 562 The Proxy Binding (P) bit is set by the sending mobility node to 563 indicate that the revoked binding(s) is a PMIPv6 binding. 565 IPv4 HoA Binding Only (V) 567 The IPv4 HoA Binding Only (V) bit is set by the sending mobility 568 node, home agent or local mobility anchor, to request the 569 receiving mobility entity the termination of the IPv4 Home Address 570 binding only as in Section 8.1, and Section 9.1.1. 572 Global (G) 574 The Global (G) bit is set by the sending mobility node, LMA or 575 MAG, to request the termination of all Per-Peer mobility Bindings 576 or Multiple Bindings which share a common identifier that are 577 served by the sending and receiving mobility entities as in 578 Section 9.1.1 and Section 10.2.1. 580 Reserved 582 These fields are unused. They MUST be initialized to zero by the 583 sender and MUST be ignored by the receiver. 585 Mobility Options 587 Variable-length field of such length that the complete Mobility 588 Header is an integer multiple of 8 octets long. This field 589 contains zero or more TLV-encoded mobility options. This document 590 does not define any new mobility option. The receiver MUST ignore 591 and skip any options which it does not understand. These mobility 592 option(s) are used by the receiving mobility entity to identify 593 the specific binding or bindings that the sending mobility entity 594 requesting to be revoked. 596 The following options are valid in a Binding Revocation Indication: 598 o Home Network Prefix option [RFC5213]. This option MAY be used 599 when the (P) bit is set. This option MUST be present when the BRI 600 is used to revoke a single PMIP binding cache entry. 602 o Mobile Node Identifier Option [RFC4283]. This option is mandatory 603 when the (P) bit is set. Additionally, if the (G) bit is set by 604 the mobile access gateway, this option carries the MAG identity. 606 o Binding Identifier mobility option [ID-MCoA]. This option is 607 mandatory if the sending mobility entity requests to terminate one 608 binding of a multi care-of addresses bindings for the same mobile 609 node. The sending mobility entity may include more than one of 610 the BID mobility options. 612 o IPv4 Home Address option which contains the mobile node home IPv4 613 address [RFC5555]. This option is included only when the IPv4 HoA 614 Binding only (V) bit is set. 616 o Alternate Care-of Address mobility option [RFC3775]. This option 617 MAY be included to indicate the Care-of Address of the mobile 618 node's binding that is being revoked. In the case when the Global 619 (G) bit set, this option identifies all the mobility bindings that 620 share the same care-of address. Additionally, if the Global (G) 621 bit set, more than one Alternate Care-of Address mobility options 622 MAY be present in the Binding Revocation Indication message. 624 If no options are present in this message, 4 octets of padding are 625 necessary and the Header Len field of the Binding Revocation Message 626 will be set to 1. 628 6.2. Binding Revocation Acknowledgement Message 630 The Binding Revocation Acknowledgement (BRA) message is a Binding 631 Revocation Message which has a MH type and a Binding 632 Revocation Type value of 2. It is used to acknowledge the receipt of 633 a Binding Revocation Indication message described in Section 6.1. 634 This packet is sent as described in Section 9.2.2, Section 10.1.2, 635 and Section 11.2. 637 When the value 2 is indicated in the Binding Revocation type field of 638 the Binding Revocation Message, the format of the Binding Revocation 639 Message Data follows the Binding Revocation Acknowledgement message 640 as in Figure 6 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | B.R. Type = 2 | Status | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Sequence # |P|V|G| Reserved | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 . . 651 . Mobility options . 652 . . 653 | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure 6: Binding Revocation Acknowledgement Message 658 Status 660 8-bit unsigned integer indicating the result of processing the 661 Binding Revocation Indication message by the receiving mobility 662 entity. Values of the Status field less than 128 indicate that 663 the Binding Revocation Indication was processed successfully by 664 the receiving node. Values greater than or equal to 128 indicate 665 that the Binding Revocation Indication was rejected by the 666 receiving node. The following status values are currently 667 defined: 669 0 success 670 1 partial success 671 128 Binding Does NOT Exist 672 129 IPv4 Home Address Option Required 673 130 Global Revocation NOT Authorized 674 131 Revoked Mobile Nodes Identity Required 675 132 Revocation Failed - MN is Attached 676 133 Revocation Trigger NOT Supported 677 134 Revocation Function NOT Supported 679 Sequence # 681 The sequence number in the Binding Revocation Acknowledgement is 682 copied from the Sequence Number field in the Binding Revocation 683 Indication. It is used by the revoking mobility entity, e.g., HA, 684 LMA, MAG, in matching this Binding Revocation Acknowledgement with 685 the outstanding Binding Revocation Indication. 687 Proxy Binding (P) 689 The Proxy Binding (P) bit is set if the (P) bit is set in the 690 corresponding Binding Revocation Indication message. 692 IPv4 HoA Binding Only (V) 694 The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in 695 the corresponding Binding Revocation Indication message. 697 Global (G) 699 The Global (G) bit is set if the (G) bit is set in the 700 corresponding Binding Revocation Indication message. 702 Reserved 704 These fields are unused. They MUST be initialized to zero by the 705 sender and MUST be ignored by the receiver. 707 Mobility Options 709 Variable-length field of such length that the complete Mobility 710 Header is an integer multiple of 8 octets long. This field 711 contains zero or more TLV-encoded mobility options. In the case 712 when the Status field is set to success, no mobility option is 713 required. The mobility option(s) is usually used to communicate 714 information of the bindings that failed the revocation procedure. 716 The following mobility options are valid in a Binding Revocation 717 Acknowledgement: 719 o Home Network Prefix option [RFC5213]. This option MAY be included 720 when the (P) bit is set. 722 o Mobile Node Identifier Option [RFC4283]. This option MAY be 723 included when the (P) bit is set. This option SHOULD be included 724 if the Home Network Prefix option is included. 726 o Binding Identifier mobility option [ID-MCoA]. This option MAY be 727 included to indicate the specific BID that the receiving node 728 failed to revoke. 730 If no options are present in this message, 4 octets of padding are 731 necessary and the Header Len field of the Binding Revocation Message 732 will be set to 1. 734 7. Binding Revocation Process Operation 736 The following subsections describe the details of the binding 737 revocation generic process by the different mobility entities. 739 7.1. Sending Binding Revocation Messages 741 When sending a Binding Revocation message, the sending mobility node, 742 initiator, constructs the packet as it would any other Mobility 743 Header with the exception of setting the MH Type field to . 745 In addition, the mobility entity which initiates the binding 746 revocation process by sending a Binding Revocation Indication 747 message, initiator, MUST construct the Binding Revocation Message 748 Data following the format of the Binding Revocation Indication 749 message as described in Section 6.1. In the BRI message, the 750 initiator MUST set the Sequence Number field to the next sequence 751 number available for Binding Revocation. Since sending Binding 752 Revocation Indication message is not done on a regular basis, a 16 753 bit sequence number field is large enough to allow the initiator to 754 match the Binding Revocation Acknowledgement to the outstanding 755 Binding Revocation Indication with (A) bit set using the sequence 756 number field only. 758 However, when the responder acknowledges the Binding Revocation 759 Indication message, the responder MUST constructs the Binding 760 Revocation message packet as it would any other Mobility Header with 761 the exception of setting the MH Type field to . It also 762 MUST construct the Binding Revocation Message Data following the 763 format of the Binding Revocation Acknowledgement message as described 764 in Section 6.2. In this case, the responder MUST set the Sequence 765 Number field by copying the value from the Sequence Number field of 766 the received Binding Revocation Indication. Additionally, it MUST 767 set the status field to a valid value that reflects the processing of 768 the received Binding Revocation Indication. 770 A mobility entity MUST secure Binding Revocation Indication and 771 Binding Revocation Acknowledgement messages with the same underlying 772 security association, e.g., IPsec SA, that has been used to secure 773 the mobile node binding registration signaling. 775 7.2. Receiving Binding Revocation Messages 777 When receiving a Binding Revocation message, the receiving mobility 778 node MUST verify the Mobility Header as described in section 9.2. of 779 [RFC3775]. If the packet is dropped due to failing any of the 780 Mobility Headers test check, the receiving node MUST follow the 781 processing rules as in Section 9.2 of [RFC3775]. If the receiving 782 node does not support the Binding Revocation Indication message and 783 does not recognize the new MH type, it sends a Binding Error message 784 with the Status field set to 2 as described in [RFC3775]. 786 Since some mobility entities, e.g., local mobility anchor and mobile 787 access gateway, are allowed to receive and possibly send a Binding 788 Revocation Indication or Binding Revocation Acknowledgement for 789 different cases, therefore, if IPsec is used to secure signaling 790 between the them, it prevents any possible man in the middle 791 reflection attack. 793 Upon receiving a packet carrying a Binding Revocation Indication or 794 Binding Revocation Acknowledgement, the receiving mobility entity 795 verifies that the packet was received protected with the security 796 association that has been used during the binding registration 797 signaling phase, e.g., an IPsec SA. 799 Upon receiving a packet carrying a Binding Revocation 800 Acknowledgement, the receiving mobility entity, initiator, MUST 801 validate that sequence number in the Sequence Number field matches 802 the sequence number of an outstanding Binding Revocation Indication 803 that was sent by the initiator. If the sequence number does not 804 match any sequence number of any of the outstanding Binding 805 Revocation Indication, the receiving node MUST silently discard the 806 message but MAY log the event. 808 If a mobility node receives a Binding Revocation Indication message 809 with the Revocation Trigger field is set to a value that NOT 810 supported, the receiving mobility node SHOULD reject the Binding 811 Revocation Indication message by sending a Binding Revocation 812 Acknowledgement message with the Status field set to "Revocation 813 Trigger NOT Supported". 815 If a mobility node receives a Binding Revocation Indication message 816 with a Revocation Trigger value that is NOT in line with the Binding 817 Revocation Indication message intent, e.g., the Global Revocation (G) 818 bit set and the Revocation Trigger field vale is a per-MN specific, 819 the receiving mobility node SHOULD reject the Binding Revocation 820 Indication message by sending a Binding Revocation Acknowledgement 821 message with the Status field set to "Revocation Function NOT 822 Supported". 824 7.3. Retransmission of Binding Revocation Indication 826 If the sending mobility entity does not receive a Binding Revocation 827 Acknowledgement in response to the outstanding Binding Revocation 828 Indication before the MINDelayBRIs timer expires, the mobility 829 entity, e.g. LMA, may retransmit the same BRI message up to the 830 BRIMaxRetriesNumber as defined in Section 12. If the revoking 831 mobility entity does not receive a Binding Revocation Acknowledgement 832 message after the maximum number of retransmits have been sent, the 833 revoking mobility entity can clean the mobile node binding cache and 834 all resources associated with this binding. The revoking mobility 835 entity may log the event. 837 8. Home Agent Operation 839 8.1. Sending Binding Revocation Indication 841 To terminate a mobile node registration and its current binding with 842 the home agent, the home agent sends a packet to the mobile node 843 containing a Binding Revocation Indication, with the packet 844 constructed as follows: 846 o The Acknowledge (A) bit MAY be set to request the mobile node to 847 send a Binding Revocation Acknowledgement upon receipt of the 848 Binding Revocation Indication. 850 o The Revocation Trigger field MUST be set to indicate to the mobile 851 node the reason for revoking its IP mobility binding with the home 852 agent. The Revocation Trigger may be used by the mobile node to 853 take further steps if necessary. 855 o The Binding Revocation Indication MUST be sent using a Type 2 856 routing header which contains the mobile node's registered IPv6 857 home address for the binding being revoked. 859 o The care-of address for the binding MUST be used as the 860 destination address in the packet's IPv6 header, unless an 861 Alternate Care-of Address mobility option is included in the 862 Binding Revocation Indication. 864 o If the home agent needs to only revoke the mobile node's IPv4 home 865 address binding, the home agent MUST set the IPv4 HoA Binding Only 866 (V) bit and MUST include the mobile node's registered IPv4 home 867 address that is being revoked in the IPv4 Home Address option. 869 The Acknowledge (A) bit in the Binding Revocation Indication requests 870 the mobile node to return a Binding Revocation Acknowledgement in 871 response to this Binding Revocation Indication. As described in 872 Section 7.3, the home agent SHOULD retransmit this Binding Revocation 873 Indication to the mobile node before terminating its IP connection 874 until it receives a matching Binding Revocation Acknowledgement or 875 the BRIMaxRetransmitNumber has been reached. 877 When the home agent sends a Binding Revocation Indication to the 878 mobile node with the (A) bit set, the home agent sets a flag in the 879 mobile node BCE to indicate that revocation is in progress and starts 880 the MINDelayBRIs timer. The home agent maintains the mobile node BCE 881 in this state until it receives a Binding Revocation Acknowledgement 882 or the BRIMaxRetransmitNumber is reached. 884 In a race condition case, the home agent may receive a Binding Update 885 from the mobile node while the mobile node's BCE has the revocation 886 in progress flag set, the home agent SHOULD handle this case based on 887 the reason for sending the Binding Revocation Indication message and 888 its local policy. In this case, if the home agent accepts the 889 Binding Update, it needs to update the mobile node BCE accordingly, 890 e.g. removing the revocation in progress flag. 892 When the home agent needs to revoke one or more of a mobile node 893 bindings that were created using Multi Care-of address registration 894 as in [ID-MCoA], the home agent MUST include all the related BID 895 mobility options that identify these bindings in the Binding 896 Revocation Indication message. In the case when the home agent needs 897 to revoke all of the mobile node bindings, the home agent SHOULD NOT 898 include any of the BID mobility options. 900 8.2. Receiving Binding Revocation Acknowledgement 902 When the home agent receives a packet carrying a valid Binding 903 Revocation Acknowledgement that was successfully processed as in 904 Section 7.2, the home agent SHOULD examine the Status field as 905 follows: 907 o If the Status field indicates that the Binding Revocation 908 Indication was processed successfully, the home agent deletes the 909 MINDelayBRIs timer and the mobile node bindings and all related 910 resources. 912 o If the Status field indicates any value other than success, the 913 home agent SHOULD examine any mobility options included in the 914 Binding Revocation Acknowledgement. The home agent MAY log the 915 appropriate event to reflect the received status. 917 9. Local Mobility Anchor Operation 919 9.1. Binding Revocation Initiator 921 9.1.1. Sending Binding Revocation Indication 923 To terminate a mobile node PMIPv6 registration and its current 924 binding with the local mobility anchor, the local mobility anchor 925 sends a packet to the mobile access gateway containing a Binding 926 Revocation Indication message following the procedure in Section 7.1 927 and the following rules: 929 o The Acknowledge (A) bit MAY be set to request the mobile access 930 gateway to send a Binding Revocation Acknowledgement upon receipt 931 of the Binding Revocation Indication. 933 o The Proxy Mobile IP (P) bit MUST be set to indicate that the 934 binding being revoked is a PMIPv6 binding. 936 o The Revocation Trigger field MUST be set to indicate to the mobile 937 access gateway the reason for removing the specified mobile node 938 PMIPv6 binding at the local mobility anchor. The Revocation 939 Trigger may be used by the mobile access gateway to learn the 940 mobile node's latest movement. 942 o In case of revoking all Per-Peer bindings, the Global (G) bit MUST 943 be set and the Revocation Trigger MUST contain a value of "Per- 944 Peer Policy" to request the mobile access gateway to remove all 945 Per-Peer bindings that are registered with the local mobility 946 anchor and hosted at this mobile access gateway. 948 o Whenever the Global (G) bit is set in the Binding Revocation 949 Indication, the Acknowledge (A) bit MUST be set to request the 950 mobile access gateway to send a Binding Revocation 951 Acknowledgement. 953 o The packet MUST contain the Mobile Node Identifier, MN-ID, option 954 which contains the mobile node's NAI that was used in the Proxy 955 Binding Update during the mobile node registration. 957 o If the Mobile Node Identifier, MN-ID, is registered in more than 958 one of the mobile node's BCE and the local mobility anchor does 959 NOT need to revoke all of the mobile node's bindings, the packet 960 MUST contain another identifier to uniquely identify the mobile 961 node binding(s) that is being revoked, e.g., at least one Home 962 Network Prefix option which contains the mobile node's registered 963 HNP for the binding being revoked. 965 o The care-of address for the binding MUST be used as the 966 destination address in the packet's IPv6 header, unless an 967 Alternate Care-of Address mobility option is included in the 968 Binding Revocation Indication message. 970 The Acknowledge (A) bit in the Binding Revocation Indication requests 971 the mobile access gateway to return a Binding Revocation 972 Acknowledgement. As described in Section 7.3, the local mobility 973 anchor SHOULD retransmit this Binding Revocation Indication before 974 deleting the mobile node IP tunnel to the mobile access gateway until 975 it receives a matching Binding Revocation Acknowledgement or the 976 BRIMaxRetransmitNumber is reached. The local mobility anchor MAY 977 delete the mobile node(s) IP tunnel immediately after sending the 978 Binding Revocation Indication and before receiving the Binding 979 Revocation Acknowledgement message. 981 When the local mobility anchor sends a Binding Revocation Indication 982 to the mobile access gateway to remove a specific binding and the 983 Acknowledge (A) bit is set, the local mobility anchor sets a flag in 984 the mobile node proxy BCE to indicate that revocation is in progress 985 and starts the MINDelayBRIs timer. The local mobility anchor SHOULD 986 maintain the mobile node proxy BCE in this state until it receives a 987 Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is 988 reached. In the case when the local mobility anchor sets the 989 Revocation Trigger field to a value which indicates inter-MAG 990 handover, the local mobility anchor MAY switch the mobile node IP 991 tunnel to the target mobile access gateway before sending the Binding 992 Revocation Indication to the source mobile access gateway. 994 In a race condition case, the local mobility anchor may receive a 995 Proxy Binding Update from the mobile access gateway while the mobile 996 node's proxy BCE has the revocation in progress flag set, the local 997 mobility anchor should handle this case based on the reason for 998 sending the Binding Revocation Indication message and its local 999 policy. In this case, if the local mobility anchor accepts the Proxy 1000 Binding Update, it needs to update the mobile node proxy BCE 1001 accordingly, e.g. removing the revocation in progress flag. 1003 When the local mobility anchor needs to revoke all mobile nodes proxy 1004 BCE that are registered with the local mobility anchor and hosted at 1005 the mobile access gateway, it MUST set the Global (G) bit and set the 1006 value of the Revocation Trigger field to "Per-Peer Policy". In this 1007 case, the local mobility anchor MUST NOT include any mobility options 1008 in the this Binding Revocation Indication message. 1010 When the local mobility anchor needs to revoke all mobile nodes proxy 1011 BCE that belong to a specific realm, e.g. @companyabc.com, that are 1012 registered with the local mobility anchor and hosted at the mobile 1013 access gateway, the local mobility anchor MUST set the Global (G) bit 1014 and set the value of the Revocation Trigger field to "Revoking 1015 Mobility Node Local Policy". In this case, the local mobility anchor 1016 MUST include a mobility option in the Binding Revocation Indication 1017 to identify the impacted bindings, e.g., MN-ID option with a wildcard 1018 NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs 1019 that need to be removed. 1021 When the mobile node is registered with multiple Home Network 1022 Prefixes for the same proxy care-of address, the local mobility 1023 anchor SHOULD include a HNP option for each registered HNP in the 1024 Binding Revocation Indication. Alternatively, it MAY include only 1025 the mobile node identifier, MN-ID, option to indicate to the mobile 1026 access gateway to remove all bindings of the specified mobile node 1027 NAI in the MN-ID option. 1029 According to Proxy Mobile IPv6 specification [RFC5213], if the local 1030 mobility anchor receives a Proxy Binding Update message from a new 1031 mobile access gateway for extending the binding lifetime of the only 1032 BCE of this mobile node with the Handoff Indicator value is set to 1033 "Inter-MAG Handover - Unknown", the local mobility anchor waits a 1034 period of MaxDelayBeforeNewBCEAssign to receive a de-registration 1035 message from the previous mobile access gateway before updating the 1036 mobile node's BCE with the new point of attachment. If a de- 1037 registration message is not received,, the local mobility anchor 1038 considers the received Proxy Binding Update message as a request for 1039 a new BCE and if processed successfully, the local mobility anchor 1040 assigns a different HNP for the new BCE. 1042 This document updates the local mobility anchor's behavior in this 1043 case. If the local mobility anchor supports the binding revocation 1044 mechanism as described in this document, it SHOULD proactively send a 1045 Binding Revocation Indication message to the previous mobile access 1046 gateway instead of waiting for a de-registration from the previous 1047 mobile access gateway. In the Binding Revocation Indication message, 1048 the (A) bit MUST be set and the Revocation Trigger MUST be set to 1049 "Inter-MAG Handover - Unknown". 1051 If the local mobility anchor sent a Binding Revocation Indication 1052 message with the Revocation Trigger field set to "Inter-MAG Handover 1053 - Unknown" and while waiting for a Binding Revocation Acknowledgement 1054 response, the following are possible conditions that the local 1055 mobility anchor MUST handle as specified below: 1057 o If the local mobility anchor receives a successful Binding 1058 Revocation Acknowledgement message or a de-registration message 1059 from the previous mobile access gateway, the local mobility anchor 1060 MUST update the mobile node BCE in a similar way as if it received 1061 a de-registration message as described in [RFC5213]. 1063 o If the local mobility anchor receives a Binding Revocation 1064 Acknowledgement message with the status field set to "Revocation 1065 Failed - MN is Attached", the local mobility anchor SHOULD update 1066 the mobile node BCE in a similar way as if it did NOT receive a 1067 de-registration before the MaxDelayBeforeNewBCEAssign timer 1068 expires by creating a new BCE as described in [RFC5213]. 1070 o If the local mobility anchor did not receive a Binding Revocation 1071 Acknowledgement message nor a de-registration Proxy Binding Update 1072 from the previous mobile access gateway after it exhausted all of 1073 the Binding Revocation Indication message retransmissions as 1074 described in Section 7.3, the local mobility anchor SHOULD update 1075 the mobile node's BCE in a similar way as if it did NOT receive a 1076 de-registration before the MaxDelayBeforeNewBCEAssign timer 1077 expires by creating a new BCE as described in [RFC5213]. Note 1078 that the local mobility anchor SHOULD use the recommended number 1079 of retransmissions for the Binding Revocation Indication message 1080 as described in Section 12 to avoid delaying the creation of a new 1081 binding cache entry for too long, if the mobile node is actually 1082 attaching to the new MAG with a different interface. 1084 When the mobile node is registered with an IPv4 proxy home address in 1085 addition to the Home Network Prefix where both of the IPv4 pHoA and 1086 HNP are bound to the same proxy CoA, the local mobility anchor MAY 1087 revoke the mobile node IPv4 proxy HoA binding to the current mobile 1088 node proxy CoA while maintaining the mobile node binding of the HNP 1089 to its current pCoA as part of the mobile node BCE. In this case, if 1090 the local mobility anchor decides to revoke the mobile node IPv4 1091 proxy HoA ONLY, it MUST send a Binding Revocation Indication message 1092 following the procedure in Section 7.1 and the following rules: 1094 o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to 1095 indicate that only the IPv4 home address binding is being revoked. 1097 o The Acknowledge (A) bit MUST be set to request the mobile access 1098 gateway to send a Binding Revocation Acknowledgement message. 1100 o The IPv4 Home Address option MUST be included with the mobile 1101 node's registered IPv4 home address that is being released in 1102 addition to the MN-ID option. 1104 o The mobile node Home Network Prefix option MUST NOT be included. 1106 o The Revocation Trigger field MUST be set to an appropriate value, 1107 e.g. "User Initiated Session(s) Termination". 1109 9.1.2. Receiving Binding Revocation Acknowledgement 1111 When the local mobility anchor receives a packet carrying a valid 1112 Binding Revocation Acknowledgement that was successfully processed as 1113 in Section 7.2 and if the mobile node BCE is in the state of 1114 Revocation in progress, the local mobility anchor SHOULD examine the 1115 Status field before clearing the mobile node related resources as 1116 follows: 1118 o If the Status field indicates that the BRI was processed 1119 successfully, the local mobility anchor delete the MINDelayBRIs 1120 timer and the mobile node proxy bindings and all associated 1121 resources. 1123 o If the Status field indicates partial success value or MN binding 1124 does not exist, the local mobility anchor SHOULD examine mobility 1125 options that are included in the Binding Revocation 1126 Acknowledgement, if any, before deleting the MINDelayBRIs timer 1127 and the mobile node associated proxy bindings and other related 1128 resources. It is based on the local mobility anchor local policy 1129 how to handle the mobile node BCE(s) that the mobile access 1130 gateway indicated it failed the revocation procedure, however, the 1131 LMA MAY log the event. 1133 9.2. Binding Revocation Responder 1135 9.2.1. Receiving Binding Revocation Indication 1137 When the local mobility anchor receives a packet carrying a Binding 1138 Revocation Indication that was successfully processed as in 1139 Section 7.2, the local mobility anchor SHOULD in addition process the 1140 message as follows: 1142 o Binding Revocation Indication is formatted as in Section 6.1 and 1143 if the (P) bit is set, the local mobility anchor MUST validate 1144 that all impacted binding(s) have the proxy binding flag set. 1146 o If the Global (G) bit is set and the Revocation Trigger value is 1147 "Per-Peer Policy", the Proxy (P) bit MUST be set and the Binding 1148 Revocation Indication SHOULD contain the mobile access gateway ID 1149 in the MN-ID option. The local mobility anchor MUST verify that 1150 the identified mobile access gateway as per the value in the MN-ID 1151 option is authorized to use the Global revocation. The mechanism 1152 the local mobility anchor uses to verify the mobile access gateway 1153 authorization is out of scope of this document. 1155 o If the Global (G) bit is set and the Revocation Trigger value is 1156 "Per-Peer Policy", and only the mobile node identifier, MN-ID, 1157 option is included, the local mobility anchor MUST revoke all 1158 mobile nodes bindings which proxy CoA is the one used as the 1159 source of the IPv6 packet that carried the Binding Revocation 1160 Indication. However, if one or more Alternate Care-of Address 1161 options are included in addition to the mobile node identifier 1162 option, the local mobility anchor MUST revoke all mobile nodes 1163 bindings which proxy Care-of Address matches one of the Care-of 1164 address(es) in the Alternate Care-of Address option(s). 1166 o The local mobility anchor identifies all impacted mobile nodes 1167 bindings and if the Acknowledgement (A) bit is set, the local 1168 mobility anchor MUST send a Binding Revocation Acknowledgement 1169 following Section 9.2.2 using the appropriate status code. 1171 o If the Global (G) bit is NOT set, the local mobility anchor SHOULD 1172 use the included mobility options to identify the impacted mobile 1173 node binding as follows: 1175 1. If only the mobile node identifier, MN-ID, option is included, 1176 the local mobility anchor MUST revoke all bindings for this 1177 mobile node which use the specified mobile node NAI. 1179 2. If the mobile node identifier, MN-ID, and the Home Network 1180 Prefix option are included, the local mobility anchor MUST 1181 only remove the specified proxy binding. 1183 3. If the mobile node identifier, MN-ID, option and more than one 1184 Home Network Prefix options are included, the local mobility 1185 anchor MUST remove all bindings which are referenced by these 1186 multiple Home Network Prefixes for the specified mobile node 1187 NAI. 1189 The Revocation Trigger field value in the received Binding Revocation 1190 Indication could be used by the local mobility anchor to log an event 1191 or update some local parameters which tracks the state of the peer 1192 mobile access gateway. 1194 9.2.2. Sending Binding Revocation Acknowledgement 1196 When the local mobility anchor receive a valid Binding Revocation 1197 Indication with the (A) bit set and after processing the Binding 1198 Revocation Indication message, the local mobility anchor sends a 1199 packet to the mobile access gateway containing a Binding Revocation 1200 Acknowledgement following the process in Section 7.1 and the 1201 following: 1203 o If the (P) bit was set in the received Binding Revocation 1204 Indication, the local mobility anchor MUST set the (P) bit in the 1205 Binding Revocation Acknowledgement. 1207 o If the Global (G) bit was set in the received Binding Revocation 1208 Indication, the local mobility anchor MUST set the (G) bit in the 1209 Binding Revocation Acknowledgement. 1211 o If the IPv4 HoA Binding Only (V) bit was set in the received 1212 Binding Revocation Indication, the local mobility anchor MUST set 1213 the (V) bit in the Binding Revocation Acknowledgement. 1215 o The local mobility anchor MUST set the Status field to a valid 1216 code that reflects the processing of the received Binding 1217 Revocation Indication. If the mobile access gateway is not 1218 authorized to use the Per-Peer Global revocation feature, the 1219 local mobility anchor MUST set the Status field to (Global 1220 Revocation NOT Authorized). 1222 o In the case that one of the bindings identified in the received 1223 Binding Revocation Indication message has already been released 1224 before receiving the it, the local mobility anchor MAY set the 1225 Status field to partial success and in this case it MAY include 1226 the mobile node identifier or the Home Network Prefix option to 1227 identify the binding(s) that failed revocation. 1229 o The destination IP address of the IPv6 packet of the Binding 1230 Revocation Acknowledgement is set to the source IP address of the 1231 received Binding Revocation Indication. 1233 10. Mobile Access Gateway Operation 1235 10.1. Binding Revocation Responder 1237 10.1.1. Receiving Binding Revocation Indication 1239 Upon receiving a packet carrying a Binding Revocation Indication, the 1240 mobile access gateway MUST validate the packet according to 1241 Section 7.2 and the following: 1243 o Binding Revocation Indication MUST be formatted as in Section 6.1 1244 and the (P) bit is set. 1246 o If the Acknowledgement (A) bit in the received Binding Revocation 1247 Indication is set, the mobile access gateway MUST send a Binding 1248 Revocation Acknowledgement following Section 10.1.2 using the 1249 appropriate status value. 1251 o If the Global (G) bit is set and the Revocation Trigger field 1252 value is "Per-Peer policy", the mobile access gateway identifies 1253 all bindings that are registered at the local mobility anchor and 1254 hosted at the mobile access gateway. This Binding Revocation 1255 Indication does not include any other mobility options. In this 1256 case, the mobile access gateway MUST send a Binding Revocation 1257 Acknowledgement with the appropriate status code to the local 1258 mobility anchor. 1260 o If the Global (G) bit is set and the Revocation Trigger field 1261 value is "Revoking Mobility Node Local Policy", the mobile access 1262 gateway MUST identify all bindings that are registered at the 1263 local mobility anchor and hosted at the mobile access gateway 1264 using the mobility option(s) included in the Binding Revocation 1265 Indication which SHOULD include at least the MN-ID option, e.g., 1266 with a wild card NAI. In this case, the mobile access gateway 1267 MUST send a Binding Revocation Acknowledgement with the 1268 appropriate status code to the local mobility anchor. 1270 o If the Global (G) bit is set and the Revocation Trigger field 1271 value is "Revoking Mobility Node Local Policy", and no mobility 1272 options are included in the Binding Revocation Indication message 1273 or the mobile access gateway is not able to identify the impacted 1274 mobile nodes bindings based on the included mobility options, the 1275 mobile access gateway MUST treat this as an error scenario. In 1276 this case, the mobile access gateway SHOULD send a Binding 1277 Revocation Acknowledgement message with status "Revoked Mobile 1278 Nodes Identity Required". 1280 o If the Revocation Trigger field value in the received Binding 1281 Revocation Indication message indicates inter-MAG handover, e.g., 1282 Inter-MAG Handover - Unknown, and the (A) bit is set, the mobile 1283 access gateway use the mobility option(s) included in the Binding 1284 Revocation Indication message to identify the mobile node binding. 1285 The mobile access gateway SHOULD validate that the mobile node is 1286 no longer attached to the mobile access gateway before sending a 1287 successful Binding Revocation Acknowledgement message to the local 1288 mobility anchor. However, if the mobile access gateway verified 1289 that the mobile node is still directly attached, the mobile access 1290 gateway MUST set the status field in the Binding Revocation 1291 Acknowledgement to "Revocation failed - MN is Attached". 1293 o If the IPv4 HoA Binding Only (V) bit in the received Binding 1294 Revocation Indication message is set, the mobile access gateway 1295 uses the MN-ID option to identify the mobile node binding entry in 1296 the BUL. It MUST verify that the IPv4 address included in the 1297 IPv4 Home Address option in the received Binding Revocation 1298 Indication is the same as the IPv4 proxy HoA that is assigned to 1299 the mobile node. After the mobile access gateway successfully 1300 validates the received IPv4 home address as the mobile node IPv4 1301 HoA, it MUST consider this as an indication to release the mobile 1302 node IPv4 proxy HoA binding to the mobile node current proxy CoA 1303 ONLY. Consequently, it MUST continue to maintain the mobile node 1304 IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA 1305 as part of the mobile node binding in the BUL entry and release 1306 all resources associated with the MN IPv4 proxy HoA binding to the 1307 MN pCoA. In this case, the mobile access gateway MUST send a 1308 Binding Revocation Acknowledgement message with the Status field 1309 is set to success. On the other hand, if the mobile access 1310 gateway is able to identify the mobile node binding using the 1311 MN-ID but failed to identify the received IPv4 proxy HoA, it MUST 1312 send a Binding Revocation Acknowledgement with Status field is set 1313 to "Binding Does NOT Exist". 1315 The Revocation Trigger field value in the received Binding Revocation 1316 Indication could be used by the mobile access gateway to define what 1317 actions the mobile access gateway could do to inform the mobile node 1318 that its IP connectivity to the current HNP has been terminated, 1319 e.g., if the Revocation Trigger field is set to "Administrative 1320 Reason", the mobile access gateway may send a RA message after 1321 setting the Home Network Prefix valid lifetime to zero. 1323 10.1.2. Sending Binding Revocation Acknowledgement 1325 When the mobile access gateway receive a valid Binding Revocation 1326 Indication with the (A) bit set and after processing it, the mobile 1327 access gateway sends a packet to the local mobility anchor containing 1328 a Binding Revocation Acknowledgement according to the procedure in 1329 Section 7.1 and the following: 1331 o The mobile access gateway MUST set the (P) bit in the Binding 1332 Revocation Acknowledgement if it is set in the received Binding 1333 Revocation Indication. 1335 o If the Global (G) bit was set in the received Binding Revocation 1336 Indication, the mobile access gateway MUST set the (G) bit in the 1337 Binding Revocation Acknowledgement. 1339 o If the IPv4 HoA Binding Only (V) bit was set in the received 1340 Binding Revocation Indication, the mobile access gateway MUST set 1341 the (V) bit in the Binding Revocation Acknowledgement. 1343 o The mobile access gateway MUST set the Status field to a valid 1344 code that reflects the processing of the received Binding 1345 Revocation Indication. 1347 o In the case that one or more of the bindings identified in the 1348 received Binding Revocation Indication message has already been 1349 released before receiving the Binding Revocation Indication, the 1350 mobile access gateway MAY set the Status field to "partial 1351 success" and include the mobile node identifier, MN-ID, or the 1352 Home Network Prefix option to identify the binding(s) that failed 1353 to be removed as part of the revocation procedure. 1355 o The destination IP address of the IPv6 packet of the Binding 1356 Revocation Acknowledgement is set to the source IP address of the 1357 received Binding Revocation Indication. 1359 10.2. Binding Revocation Initiator 1360 10.2.1. Sending Binding Revocation Indication 1362 The mobile access gateway could send a Binding Revocation Indication 1363 message to indicate the termination of multiple mobile node bindings, 1364 e.g., when using the global revocation with the Global (G) bit set. 1365 In this case when an event occurs which requires the mobile access 1366 gateway to inform the local mobility anchor to terminate all mobile 1367 nodes bindings which are registered at the local mobility anchor and 1368 the mobile access gateway, the mobile access gateway sends a Binding 1369 Revocation Indication message following Section 7.1 and the 1370 following: 1372 o The Acknowledge (A) bit MUST be set in the to request the local 1373 mobility anchor to send a Binding Revocation Acknowledgement upon 1374 receipt of the Binding Revocation Indication. 1376 o The Proxy Binding (P) bit MUST be set to indicate that bindings 1377 that being revoked is a PMIPv6 binding. 1379 o The Global (G) bit MUST be set and the Revocation Trigger MUST 1380 contain a value of "Per-Peer Policy" in the Binding Revocation 1381 Indication to request the local mobility anchor to remove all Per- 1382 Peer bindings that are registered with the local mobility anchor 1383 and hosted at this mobile access gateway. In this case, the MN-ID 1384 option MUST be included in the Binding Revocation Indication and 1385 contain the mobile access gateway identity. In addition, the 1386 mobile access gateway MAY include one or more Alternate Care-of 1387 Address option(s). The Alternate Care-of Address option(s) 1388 contain the proxy Care-of address(es) which their bindings are 1389 being impacted by this Binding Revocation Indication message. 1391 o The mobile access gateway address MAY be used as the source 1392 address in the packet's IPv6 header. 1394 The Acknowledge (A) bit in the Binding Revocation Indication requests 1395 the local mobility anchor to return a Binding Revocation 1396 Acknowledgement in response to this Binding Revocation Indication. 1397 As described in Section 7.3, the mobile access gateway SHOULD 1398 retransmit this Binding Revocation Indication to the local mobility 1399 anchor until it receives a matching Binding Revocation 1400 Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile 1401 access gateway MAY delete the mobile nodes IP tunnels immediately 1402 after sending the Binding Revocation Indication and before receiving 1403 a Binding Revocation Acknowledgement message from the LMA. 1405 10.2.2. Receiving Binding Revocation Acknowledgement 1407 When the mobile access gateway receives a packet carrying a valid 1408 Binding Revocation Acknowledgement that was successfully processed 1409 according to Section 7.2, the mobile access gateway MUST process the 1410 received Binding Revocation Acknowledgement as per the followings: 1412 o When the mobile access gateway receives a packet carrying a valid 1413 Binding Revocation Acknowledgement and the Global (G) and Proxy 1414 Binding (P) bits are set and the mobile nodes BCEs are in the 1415 state of Revocation in Progress, the mobile access gateway SHOULD 1416 examine the Status field as follows: 1418 o If the Status field indicates that the Binding Revocation 1419 Indication was processed successfully, the mobile access gateway 1420 delete the MINDelayBRIs timer and the mobile nodes proxy bindings 1421 and all associated resources. 1423 o If the Status field indicates (Global Revocation NOT Authorized), 1424 the mobile access gateway is not authorized to participate in a 1425 Per-Peer Global Revocation. The mobile access gateway SHOULD NOT 1426 retry sending a Binding Revocation Indication with the Global (G) 1427 bit set to the same local mobility agent. The mobile access 1428 gateway should raise an alarm or log an event to indicate this 1429 rejection. 1431 11. Mobile Node Operation 1433 11.1. Receiving Binding Revocation Indication 1435 Upon receiving a packet carrying a Binding Revocation Indication, the 1436 mobile node MUST validate the packet according to Section 7.2 and the 1437 following tests: 1439 o The mobile node MUST verify that the IP address in the Type 2 1440 routing header is its Home Address and that its Binding Update 1441 List contains an entry for that Home Address. If one of the 1442 tests, fails the mobile node SHOULD silently discard the received 1443 Binding Revocation Indication message. 1445 o If the Acknowledgement (A) bit is set in the Binding Revocation 1446 Indication and its Binding Update List contains an entry for the 1447 IP address in the Type 2 routing header, the mobile node MUST send 1448 a Binding Revocation Acknowledgement. However, in all other cases 1449 when the (A) bit is set in the BRI, the mobile node SHOULD send a 1450 Binding Revocation Acknowledgement. In all cases, the mobile node 1451 MUST follow Section 11.2 and send a Binding Revocation 1452 Acknowledgement using the appropriate status code. 1454 o If the IPv4 HoA Binding Only (V) bit is set in the received BRI 1455 message, the mobile node MUST verify that there is an IPv4 Home 1456 Address option in the received Binding Revocation Indication and 1457 the IPv4 address included in the IPv4 Home Address option is the 1458 same as its IPv4 HoA that is assigned to the mobile node. If this 1459 verification is successful, the mobile node MUST consider this 1460 Binding Revocation Indication as an indication to release the 1461 mobile node IPv4 HoA binding ONLY to its current Care-of Address. 1462 Consequently, the mobile node MUST continue to maintain its IPv6 1463 HoA binding to the current CoA as part of the mobile node binding 1464 in the BUL entry and release all resources associated with the MN 1465 IPv4 HoA binding. In this case, the mobile node MUST send a 1466 Binding Revocation Acknowledgement message with the Status field 1467 is set to "success". On the other hand, if the IPv4 Home Address 1468 Option was NOT included in the received BRI with the (V) bit set, 1469 the MN SHOULD send a Binding Revocation Acknowledgement message 1470 with the Status field set to "IPv4 Home Address Option Required". 1471 Additionally, if the IPv4 HoA received in the IPv4 Home Address 1472 Option is NOT the one assigned to the mobile node, the mobile node 1473 SHOULD send a Binding Revocation Acknowledgement with the status 1474 field set to "Binding Does NOT Exist". 1476 o The mobile node MUST verify that the (P) bit in the Binding 1477 Revocation Indication is NOT set. If the (P) bit is set, the 1478 mobile node MUST silently discard the Binding Revocation 1479 Indication message. 1481 o If the mobile node has registered multiple care-of addresses with 1482 its home agent, the mobile node MUST verify which binding is being 1483 revoked by examining the content of the Binding Revocation 1484 Indication message. If the mobile node received a Binding 1485 Revocation Indication with a single or more than one BID options 1486 and its home address is included in the Type 2 routing header, the 1487 mobile node MUST consider all of the care-of address(es) 1488 binding(s), identified in the BID options, with this home address 1489 are being revoked. 1491 o If the mobile node has multi Care-of Address bindings with its 1492 home agent and received a Binding Revocation Indication, without 1493 any BID option included and its home address was included in the 1494 Type 2 routing header, the mobile node MUST consider all of its 1495 registered care-of addresses bindings with this home address are 1496 being revoked. 1498 The Revocation Trigger field value in the received Binding Revocation 1499 Indication could be used by the mobile node to define what action the 1500 mobile node could do to be able to register again and receive its IP 1501 mobility service, e.g., contacting its home operator. 1503 11.2. Sending Binding Revocation Acknowledgement 1505 When the mobile node receives a Binding Revocation Indication from 1506 its home agent, the mobile node processes the received Binding 1507 Revocation Indication as in Section 11.1. If the mobile node is 1508 required to send a Binding Revocation Acknowledgement message in 1509 response to the received Binding Revocation Indication, the mobile 1510 node sends a packet to its home agent containing a Binding Revocation 1511 Acknowledgement according to the procedure in Section 7.1 and the 1512 following: 1514 o The mobile node MUST set the Status field to an appropriate value. 1515 The mobile node sets the Status field to success to reflect that 1516 it has received the Binding Revocation Indication and acknowledge 1517 that its IP connectivity with its home agent has been revoked. 1519 o The destination IP address of the IPv6 packet of the Binding 1520 Revocation Acknowledgement is set to the source IP address of the 1521 received IPv6 packet of the Binding Revocation Indication. The 1522 Mobile Node MUST include its home address in the Home Address 1523 Destination Option. 1525 12. Protocol Configuration Variables 1527 Any mobility entity which is allowed to invoke the binding revocation 1528 procedure by sending a Binding Revocation Indication message SHOULD 1529 allow the following variables to be configured. 1531 BRI Maximum Number of Retries (BRIMaxRetriesNumber) 1533 This variable specifies the maximum Number of times a mobility 1534 entity can retransmit a Binding Revocation Indication message 1535 before receiving a Binding Revocation Acknowledgement message. 1536 The default value for this parameter is 1. 1538 Minimum Delay Between BRI messages (MINDelayBRIs) 1540 This variable specifies the delay time in seconds before the 1541 revoking mobility entity retransmits a BRI message. The default 1542 is 1 second but not less than 0.5 seconds. 1544 13. IANA Considerations 1546 This specification defines a new Binding Revocation Message using a 1547 new Mobility Header Type , as described in Section 6. The 1548 new Mobility Header type value needs to be assigned from the same 1549 numbering space as allocated for the other Mobility Header types. 1551 This document also creates a new name space "Binding Revocation Type" 1552 which indicates the type of the binding revocation message. The 1553 current binding revocation message types are described in Section 6.1 1554 and Section 6.2, and are the following: 1556 0 Reserved 1557 1 Binding Revocation Indication 1558 2 Binding Revocation Acknowledgement 1559 All other values are reserved 1561 Future values of the Binding Revocation Type can be allocated using 1562 Standards Action or IESG Approval [RFC2434]. 1564 In addition, this document also creates a second new namespace for 1565 the Revocation Trigger which indicates the reason behind sending the 1566 Binding Revocation Indication message. The current Revocation 1567 Trigger values are described in Section 6.1, and are the following: 1569 Reserved and Per-MN Revocation Trigger Values: 1570 0 Reserved 1571 1 Unspecified 1572 2 Administrative Reason 1573 3 Inter-MAG Handover - same Access Type 1574 4 Inter-MAG Handover - different Access Type 1575 5 Inter-MAG Handover - Unknown 1576 6 User Initiated Session(s) Termination 1577 7 Access Network Session(s) Termination 1578 8 Possible Out-of Sync BCE State 1579 250-255 Reserved For Testing Purposes only 1580 All other values are Reserved 1582 Global Revocation Trigger Values: 1583 128 Per-Peer Policy 1584 129 Revoking Mobility Node Local Policy 1586 Future values of the Revocation Trigger can be allocated using 1587 Standards Action or IESG Approval [RFC2434]. 1589 Furthermore, this document creates a third new name space "Status 1590 Code" for the Status field in the Binding Revocation Acknowledgement 1591 message. The current values are described in Section 6.2, and are 1592 the following: 1594 0 success 1595 1 partial success 1596 128 Binding Does NOT Exist 1597 129 IPv4 Home Address Option Required 1598 130 Global Revocation NOT Authorized 1599 131 Revoked Mobile Nodes Identity Required 1600 132 Revocation Failed - MN is Attached 1601 133 Revocation Trigger NOT Supported 1602 134 Revocation Function NOT Supported 1604 Future values of the Status field can be allocated using Standards 1605 Action or IESG Approval [RFC2434]. 1607 All fields labeled "Reserved" are only to be assigned through 1608 Standards Action or IESG Approval. 1610 14. Security Considerations 1612 The protocol described here uses the same security association 1613 between the mobile node and the home agent or the mobile access 1614 gateway and the local mobility anchor that has been used to exchange 1615 the corresponding MIPv6 or PMIPv6 Binding Update and Binding 1616 Acknowledgement when the session was established. If IPsec is used, 1617 the SPD of this IPsec SA MUST allow the MH type for the Binding 1618 Revocation Message defined in this document. 1620 However, in the case when the mobile access gateway sends a Binding 1621 Revocation Indication message with the Global (G) bit is set and the 1622 Revocation Trigger field is set to "Per-Peer policy", the local 1623 mobility anchor MUST verify that the mobile access gateway is 1624 authorized to use Per-Peer Global Revocation. 1626 15. Acknowledgements 1628 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1629 Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay 1630 Devarapalli, and Joel Hortelius for their review and comments of this 1631 draft and all colleagues who have supported the advancement of this 1632 draft effort. 1634 16. References 1635 16.1. Normative References 1637 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1638 Requirement Levels", BCP 14, RFC 2119, March 1997. 1640 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1641 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1642 October 1998. 1644 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1645 in IPv6", RFC 3775, June 2004. 1647 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1648 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1649 (MIPv6)", RFC 4283, November 2005. 1651 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1652 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1654 [ID-PMIP6-IPv4] 1655 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1656 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-10 1657 (work in progress), March 2009. 1659 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1660 "Multiple Care-of Addresses Registration", 1661 draft-ietf-monami6-multiplecoa-12 (work in progress), 1662 March 2009. 1664 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1665 Routers", RFC 5555, June 2009. 1667 16.2. Informative References 1669 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1670 August 2002. 1672 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1673 Mobile IPv4", RFC 3543, August 2003. 1675 Authors' Addresses 1677 Ahmad Muhanna 1678 Nortel 1679 2221 Lakeside Blvd. 1680 Richardson, TX 75082 1681 USA 1683 Email: amuhanna@nortel.com 1685 Mohamed Khalil 1686 Nortel 1687 2221 Lakeside Blvd. 1688 Richardson, TX 75082 1689 USA 1691 Email: mkhalil@nortel.com 1693 Sri Gundavelli 1694 Cisco Systems 1695 170 West Tasman Drive 1696 San Jose, CA 95134 1697 USA 1699 Email: sgundave@cisco.com 1701 Kuntal Chowdhury 1702 Starent Networks 1703 30 International Place 1704 Tewksbury, MA 01876 1705 USA 1707 Email: kchowdhury@starentnetworks.com 1709 Parviz Yegani 1710 Juniper Networks 1711 1194 North Mathilda Avenue 1712 Sunnyvale, CA 94089 1713 USA 1715 Email: pyegani@juniper.net