idnits 2.17.1 draft-ietf-mext-binding-revocation-08.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2009) is 5361 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 5226 (Obsoleted by RFC 8126) ** 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: February 13, 2010 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Startent Networks 9 P. Yegani 10 Juniper Networks 11 August 12, 2009 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-08.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. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on February 13, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 This document defines a binding revocation mechanism to terminate a 63 mobile node's mobility session and the associated resources. These 64 semantics are generic enough and can be used by mobility entities in 65 the case of Mobile IPv6 and its extensions. This mechanism allows 66 the mobility entity which initiates the revocation procedure to 67 request its corresponding one to terminate either one, multiple or 68 all specified binding cache entries. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 74 2.1. Conventions used in this document . . . . . . . . . . . . 5 75 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5 77 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 6 78 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 7 79 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 8 80 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 9 81 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 82 Revocation . . . . . . . . . . . . . . . . . . . . . . 10 83 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11 84 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 12 85 5. Binding Revocation Messages over IPv4 Transport Network . . . 12 86 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 13 87 6.1. Binding Revocation Indication Message . . . . . . . . . . 14 88 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 17 89 7. Binding Revocation Process Operation . . . . . . . . . . . . . 20 90 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 20 91 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 20 92 7.3. Retransmission of Binding Revocation Indication . . . . . 22 93 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 94 8.1. Sending Binding Revocation Indication . . . . . . . . . . 22 95 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 23 96 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24 97 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24 98 9.1.1. Sending Binding Revocation Indication . . . . . . . . 24 99 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 28 100 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29 101 9.2.1. Receiving Binding Revocation Indication . . . . . . . 29 102 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 30 103 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 31 104 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 31 105 10.1.1. Receiving Binding Revocation Indication . . . . . . . 31 106 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 33 107 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 33 108 10.2.1. Sending Binding Revocation Indication . . . . . . . . 33 109 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 34 110 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 35 111 11.1. Receiving Binding Revocation Indication . . . . . . . . . 35 112 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 36 113 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 37 114 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 115 14. Security Considerations . . . . . . . . . . . . . . . . . . . 39 116 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 117 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 118 16.1. Normative References . . . . . . . . . . . . . . . . . . . 40 119 16.2. Informative References . . . . . . . . . . . . . . . . . . 40 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 122 1. Introduction 124 In the case of Mobile IPv6 and for administrative reason, sometimes 125 it becomes necessary to inform the mobile node that its registration 126 has been revoked and the mobile node is no longer able to receive IP 127 mobility service using its Home Address. A similar Mobile IPv4 128 registration revocation mechanism [RFC3543] has been specified by 129 IETF for providing a revocation mechanism for sessions that were 130 established using Mobile IPv4 registration [RFC3344]. 132 This document specifies a binding revocation mechanism that can be 133 used to revoke a mobile node's mobility session(s). The same 134 mechanism can be used to revoke bindings created using Mobile IPv6 135 [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 136 [RFC5213]. The proposed revocation mechanism uses a new MH type 137 for revocation signaling which is applicable to Mobile 138 IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any 139 two IP mobility entities. As an example, this mechanism allows a 140 local mobility anchor (LMA), involved in providing IP mobility 141 services to a mobile node, to notify the mobile access gateway (MAG) 142 of the termination of a mobile node binding registration. In another 143 example, a mobile access gateway can use this mechanism to notify its 144 local mobility anchor peer with a bulk termination of all or a subset 145 of proxy mobile IPv6 (PMIPv6) bindings that are registered with the 146 local mobility anchor and currently being served by the mobile access 147 gateway. 149 2. Conventions & Terminology 151 2.1. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 2.2. Terminology 159 All the general mobility related terminology and abbreviations are to 160 be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile 161 IPv6 [RFC5213] specifications. 163 3. Binding Revocation Protocol and Use Cases Overview 165 This specification specifies a generic binding revocation mechanism 166 where a mobility node can communicate to the mobile node or another 167 mobility node the identity of the the mobile node registration 168 binding that is being terminated. In the case when this mechanism is 169 used for bulk termination or multiple bindings, the identities of 170 these bindings are communicated to the mobile node or mobility node 171 using the same generic mechanism. The following subsections describe 172 the protocol overview and applicable use cases. 174 3.1. Binding Revocation Protocol 176 In the case of Mobile IPv6, if the home network decides to terminate 177 the service of the mobile node, the home agent sends a Binding 178 Revocation Indication (BRI) message to the mobile node. The home 179 agent includes the home address (HoA) of the mobile node in the Type 180 2 routing header as specified in [RFC3775] to indicate the impacted 181 mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) 182 [RFC5555], the home agent may include the IPv4 Home Address option 183 with the mobile node assigned home IPv4 address. Additionally, if 184 the mobile node registered multiple care-of addresses [ID-MCoA], the 185 home agent includes the Binding Identifier (BID) option(s) in the 186 Binding Revocation Indication message to identify which binding is 187 being revoked. When the mobile node receives a Binding Revocation 188 Indication message with its HoA included in the Type 2 routing header 189 and the Acknowledge (A) bit is set, the mobile node responds by 190 sending a Binding Revocation Acknowledgement (BRA) message. 192 Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation 193 procedure can be initiated by the local mobility anchor by sending a 194 Binding Revocation Indication message to communicate the termination 195 of a mobile node registration binding to the mobile access gateway. 196 In this case, the local mobility anchor includes the mobile node Home 197 Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option 198 [RFC4283] to indicate to the mobility access gateway the identity of 199 the PMIPv6 binding that needs to be terminated. When the mobile 200 access gateway receives the Binding Revocation Indication message 201 with the (A) bit set, the mobile access gateway responds to the local 202 mobility anchor by sending a Binding Revocation Acknowledgement 203 message. 205 On the other hand, the mobile access gateway usually sends a de- 206 registration message by sending a Proxy Binding Update with a 207 lifetime of zero to indicate to the local mobility anchor of the 208 termination of the PMIPv6 mobile node binding registration. In this 209 case, the mobile access gateway includes the MN-HNP option, the MN-ID 210 option and all other required mobility options as per [RFC5213] in 211 order for the local mobility anchor to identify the mobile node 212 PMIPv6 binding. Additionally, in the case when the mobile access 213 gateway communicates a bulk termination of PMIPv6 mobility sessions, 214 the mobile access gateway sends a Binding Revocation Indication 215 message with the (G) and (A) bits set and includes the mobile access 216 gateway identity in the MN-ID option. When the local mobility anchor 217 receives such Binding Revocation Indication message, it ensures that 218 the mobile access gateway is authorized to send such bulk termination 219 message and then processes the Binding Revocation Indication message 220 accordingly. If the local mobility anchor processes the Binding 221 Revocation Indication message successfully, the local mobility anchor 222 responds to the mobile access gateway by sending Binding Revocation 223 Acknowledgement message. 225 In any of the above cases, the initiator of the binding revocation 226 procedure, e.g., home agent, local mobility anchor, mobile access 227 gateway, uses the Revocation Trigger field in the Binding Revocation 228 Indication message to indicate to the receiving node the reason for 229 initiating the revocation procedure. 231 3.2. MIPv6 and DSMIP6 Use Case 233 Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 234 session(s) when the home agent needs to inform the mobile node that 235 its binding registration has been revoked, e.g. for an administrative 236 reason. This mechanism enables the user to react to the revocation, 237 e.g., reinstate its interrupted Mobile IPv6 services. 239 In this case, the home agent sends a Binding Revocation Indication 240 message to indicate to the mobile node that its current mobile IPv6 241 (MIPv6) binding has been revoked and it no longer able to receive IP 242 mobility service. The home agent includes the HoA in Type 2 routing 243 header as used in [RFC3775] and sets the Revocation Trigger field to 244 a proper value, e.g., Administrative Reason. In the case of DSMIPv6 245 session, the home agent may additionally include the mobile node 246 assigned IPv4 Home Address in the IPv4 Home Address option. When the 247 mobile node receives the Binding Revocation Indication message, it 248 sends a Binding Revocation Acknowledgement message as described in 249 Section 11.2 to the home agent. Figure 1 illustrates the message 250 sequencing when home agent revokes a mobile node binding 251 registration. 253 MN HA 254 | | 255 | HoA in Type 2 Hdr | 256 |<<<------------... + ...-----------------| 257 | BRI [seq.#, A bit, Revocation Trigger] | 258 | | 259 | | 260 | BRA (HoA in Dest. Option)[seq.#, Status] | 261 |---------------------------------------->>>| 262 | | 263 | | 265 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 267 3.3. Multi-Care of Addresses (Monami6) Use Case 269 In the case of multiple care-of addresses registration [ID-MCoA], the 270 home agent maintains different binding for each pair of care-of 271 address and home address. These bindings are also indexed and 272 identified during the mobile node registration using a BID mobility 273 option. The HA may revoke one or multiple bindings for the same 274 mobile node home address. 276 If the home agent revokes a single binding for a mobile node with 277 multiple care-of addresses registration, the home agent sends a 278 Binding Revocation Indication message to the mobile node with the 279 corresponding BID option included. If more than one of the mobile 280 node registered care-of addresses need to be revoked, the home agent 281 includes all the corresponding BID options in the same Binding 282 Revocation Indication message. Figure 2 illustrates the message flow 283 when the home agent revokes two registered Care-of addresses for the 284 same mobile node in a single Binding Revocation Indication message. 286 HA Binding Cache 287 ================ 288 MN-BID1 [CoA1+HoA] 289 MN HA MN-BID2 [CoA2+HoA] 290 | | MN-BID3 [CoA3+HoA] 291 | | MN-BID4 [CoA4+HoA] 292 | HoA in Type 2 Hdr | 293 |<<<<-------------- + ---------------------| 294 | BRI [seq.#, A bit, R. Trigger, BID1, BID4] | 295 | | 296 | | 297 | BRA (HoA in Dest. Option) [seq.#, Status] | 298 |---------------------------------------->>>>| 299 | | 300 | | 302 Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings 304 Additionally, the home agent may revoke all of the mobile node 305 registered bindings, by sending a BRI message without including any 306 BID options while the HoA is included in the Type 2 routing header. 307 Figure 1 illustrates the message flow when the home agent revokes all 308 registered Care-of addresses bindings for a mobile node in a single 309 Binding Revocation Indication message. 311 3.4. Proxy MIPv6 Use Case 313 Since the mobile node does not participate in the mobility mechanism 314 in the case of PMIPv6, there are many scenarios where Binding 315 Revocation mechanism is needed to clean resources and make sure that 316 the mobility entities, i.e., mobile access gateway and local mobility 317 anchor, are always synchronized with respect to the status of the 318 existing PMIPv6 bindings. The binding revocation mechanism is 319 generic enough that can be used for all Proxy Mobile IPv6 scenarios 320 that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. 322 When the mobile access gateway receives a Binding Revocation 323 Indication message as in Section 10.1.1, the mobile access gateway 324 sends a Binding Revocation Acknowledgement message to the local 325 mobility anchor following the rules described in Section 10.1.2. 326 Similarly, if the local mobility anchor receives a Binding Revocation 327 Indication message with the (A) bit is set, the local mobility anchor 328 responds to the mobile access gateway by sending a Binding Revocation 329 Acknowledgement message. 331 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation 333 The local mobility anchor may send a Binding Revocation Indication 334 message to the mobile access gateway, hosting a specific PMIPv6 335 binding, with the appropriate value in the revocation trigger field 336 to indicate that the mobile node binding has been terminated and the 337 mobile access gateway can clean up the applicable resources. When 338 the mobile access gateway receives a Binding Revocation Indication 339 message, the mobile access gateway identifies the respected binding 340 and if the (A) bit was set in the received Binding Revocation 341 Indication message, it sends a Binding Revocation Acknowledgement 342 message to the local mobility anchor. In this case, the mobile 343 access gateway could send a Router Advertisement message to the 344 mobile node with the home network prefix valid lifetime set to zero. 346 As an example, Figure 3, illustrates the message sequence for 347 revoking a mobile node binding at the source mobile access gateway 348 during the mobile node inter-MAG handover. During the inter-MAG 349 handover, the mobile node moves from the source MAG to the target 350 MAG. The target MAG sends a Proxy Binding Update with the new care- 351 of-address to the local mobility anchor to update the mobile node's 352 point of attachment. Since the mobile node binding at the local 353 mobility anchor points to the source MAG and upon receiving the Proxy 354 Binding Update from the target MAG, the local mobility anchor updates 355 the MN BCE and send a Proxy Binding Acknowledgement to the target 356 MAG. The local mobility anchor can send a Binding Revocation 357 Indication message with the appropriate revocation trigger value, 358 e.g. inter-MAG handover - different Access Types, to the source MAG 359 in order to clean up the applicable resources reserved for the 360 specified mobile node binding. The mobile access gateway 361 acknowledges the Binding Revocation Indication message by sending a 362 Binding Revocation Acknowledgement message to indicate the success or 363 failure of the termination of the mobile node's binding. 365 The process identified above can also be used by the local mobility 366 anchor in scenarios other than the inter-MAG handover with the proper 367 revocation trigger value to indicate to the peer mobile access 368 gateway that a specific PMIPv6 binding or bindings have been revoked. 370 oldMAG newMAG LMA 371 | | | 372 | | PBU | 373 | |--------------------------->| 374 | | PBU triggers 375 | | BRI Msg to oldMAG 376 | | | 377 | | PBA | 378 | |<---------------------------| 379 | | | 380 | | | 381 | BRI [seq.#, R. Trigger, P, A bits, NAI] | 382 |<-----------------------------------------| 383 | | | 384 | | | 385 | | | 386 | | | 387 | BRA [seq.#, Status, P bit] | 388 |----------------------------------------->| 389 | | | 390 | | | 392 Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover 394 In addition, the local mobility anchor can send a Binding Revocation 395 Indication message to indicate that all bindings which are hosted by 396 the peer mobile access gateway and registered with the local mobility 397 anchor are being revoked by setting the (G) bit as described in 398 Section 9.1.1. 400 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 402 The mobile access gateway sends a BRI message with the (G) bit is set 403 to indicate that all mobility bindings which are registered at the 404 local mobility anchor and attached to the mobile access gateway are 405 being revoked as in Section 10.2.1. When the local mobility anchor 406 receives a Binding Revocation Indication message with the (G) bit is 407 set from a specified mobile access gateway, the local mobility anchor 408 first checks if the mobile access gateway is authorized to use global 409 revocations and then responds with the appropriate status code by 410 sending a Binding Revocation Acknowledgement message as in 411 Section 9.2.2. 413 4. Security Model 415 The binding revocation protocol described here uses the same security 416 association between the mobile node and the home agent or the mobile 417 access gateway and the local mobility anchor that has been used to 418 exchange the corresponding MIPv6 or PMIPv6 Binding Update and Binding 419 Acknowledgement when the mobile node binding was created. If IPsec 420 is used, the traffic selectors associated with the SPD entry 421 protecting the Binding Update and Binding Acknowledgement MUST be 422 extended to include Binding Revocation Signaling MH type . 423 Extending the traffic selectors of the SPD entry in order to reuse 424 the SA protecting Binding Update and Binding Acknowledgement (instead 425 of creating new ones) ensures that those SA will be up and running 426 when the revoking entity needs to send a binding revocation signaling 427 message. 429 Additionally, in the case when the local mobility anchor receives a 430 Binding Revocation Indication which indicates a bulk termination 431 where the (G) bit is set and the Revocation Trigger field is set to 432 "Per-Peer Policy", the local mobility anchor MUST verify that the 433 mobile access gateway sending the binding revocation indication 434 message is authorized to invoke global revocation. 436 5. Binding Revocation Messages over IPv4 Transport Network 438 In some deployments, the network between the mobile access gateway 439 and the local mobility anchor may only support IPv4 transport. 440 Another case is when a mobile node which support client mobile IPv6 441 roam to an access network where only IPv4 addressing and transport is 442 supported. In this case, the mobile node is required to register an 443 IPv4 home address with its home agent using a mobile IPv6 Binding 444 Update message. 446 If the Proxy Binding Update and Proxy Binding Acknowledgment messages 447 or the Binding Update and Binding Acknowledgement messages are sent 448 using UDP encapsulation to traverse NATs, then the Binding Revocation 449 messages are sent using the same UDP encapsulation. The same UDP 450 port that was used for exchanging the Proxy Binding Update and Proxy 451 Binding Acknowledgement or the Binding Update and Binding 452 Acknowledgement messages will also be used when transporting Binding 453 Revocation messages over IPv4 using UDP encapsulation. In other 454 words, the destination UDP port of the Binding Revocation Indication 455 message MUST be set to the source UDP port of the latest successfully 456 processed Proxy Binding Update or Binding Update message which is 457 already saved in the mobile node BCE. For more details on tunneling 458 Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see 459 [ID-PMIP6-IPv4] and [RFC5555], respectively. 461 6. Binding Revocation Message 463 This section defines the Binding Revocation Message format using a MH 464 Type as illustrated in Figure 4. The value in the Binding 465 Revocation Type field defines whether the Binding Revocation message 466 is a Binding Revocation Indication or Binding Revocation 467 Acknowledgement. If the Binding Revocation type field is set to 1, 468 the Binding Revocation Message is a Binding Revocation Indication as 469 in Section 6.1. However, if the value is 2, it is a Binding 470 Revocation Acknowledgement message as in Section 6.2. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Payload Proto | Header Len | MH Type | Reserved | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Checksum | B.R. Type | | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 479 | | 480 . Binding Revocation Message Data . 481 | | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 Figure 4: Binding Revocation Message 486 MH Type 488 which identifies the mobility message as a Binding 489 Revocation message. 491 Reserved 493 8-bit field reserved for future use. The value MUST be 494 initialized to zero by the sender, and MUST be ignored by the 495 receiver. 497 Checksum 499 16-bit unsigned integer. This field contains the checksum of the 500 Mobility Header. The checksum is calculated as described in 501 [RFC3775]. 503 Binding Revocation Type 505 8-bit unsigned integer. It defines the type of the Binding 506 Revocation Message. It can be assigned one of the following 507 values: 509 0 Reserved 510 1 Binding Revocation Indication Message 511 2 Binding Revocation Acknowledgement Message 512 All other values are reserved 514 Binding Revocation Message Data 516 The Binding Revocation Message Data follows the Binding Revocation 517 Message format that is defined in this document for the specified 518 value in the Binding Revocation Type field. In this 519 specification, it is either a Binding Revocation Indication as in 520 Section 6.1 or Binding Revocation Acknowledgement as in 521 Section 6.2. 523 6.1. Binding Revocation Indication Message 525 The Binding Revocation Indication (BRI) message is a Binding 526 Revocation Message which has a MH type and a Binding 527 Revocation Type value of 1. It is used by the revoking mobility node 528 to inform the receiving mobility entity of the identity of a specific 529 binding or bindings which IP mobility service have been revoked. 530 Binding Revocation Indication message is sent as described in 531 Section 8.1, Section 9.1.1, and Section 10.2.1. 533 When the value 1 is indicated in the B. R. type field of the Binding 534 Revocation Message, the format of the Binding Revocation Message Data 535 follows the Binding Revocation Indication message as in Figure 5 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | B.R. Type = 1 | R. Trigger | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Sequence # |A|P|V|G| Reserved | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 . . 546 . Mobility options . 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 5: Binding Revocation Indication Message 551 Revocation Trigger 553 8-bit unsigned integer indicating the event which triggered the 554 revoking node to send the BRI message. The Reserved and Per-MN 555 Revocation Triggers value are less than 128 except the reserved 556 values 250-255. The per-MN revocation triggers is used when the 557 BRI message intends to revoke one or more bindings for the same 558 mobile node. The Global Revocation Trigger values are greater 559 than 128 and less than 250 and used in the BRI message with the 560 (G) bit set for global revocation. The following Revocation 561 Trigger values are currently defined: 563 Reserved and Per-MN Revocation Trigger: 564 0 Reserved 565 1 Unspecified 566 2 Administrative Reason 567 3 Inter-MAG Handover - same Access Type 568 4 Inter-MAG Handover - different Access Type 569 5 Inter-MAG Handover - Unknown 570 6 User Initiated Session(s) Termination 571 7 Access Network Session(s) Termination 572 8 Possible Out-of Sync BCE State 573 250-255 Reserved For Testing Purposes only 574 All other values are Reserved 576 Global Revocation Trigger: 577 128 Per-Peer Policy 578 129 Revoking Mobility Node Local Policy 580 Sequence # 582 A 16-bit unsigned integer used by the sending mobility node to 583 match a returned Binding Revocation Acknowledgement with this 584 Binding Revocation Indication. It could be a random number. 586 Acknowledge (A) 588 The Acknowledge (A) bit is set by the sending mobility node, e.g. 589 LMA, HA, or MAG, to request a Binding Revocation Acknowledgement 590 be returned upon receipt of the Binding Revocation Indication as 591 in Section 8.1, Section 9.1.1, and Section 10.2.1. 593 Proxy Binding (P) 595 The Proxy Binding (P) bit is set by the sending mobility node to 596 indicate that the revoked binding(s) is a PMIPv6 binding. 598 IPv4 HoA Binding Only (V) 600 The IPv4 HoA Binding Only (V) bit is set by the sending mobility 601 node, home agent or local mobility anchor, to request the 602 receiving mobility entity the termination of the IPv4 Home Address 603 binding only as in Section 8.1, and Section 9.1.1. 605 Global (G) 607 The Global (G) bit is set by the sending mobility node, LMA or 608 MAG, to request the termination of all Per-Peer mobility Bindings 609 or Multiple Bindings which share a common identifier that are 610 served by the sending and receiving mobility entities as in 611 Section 9.1.1 and Section 10.2.1. 613 Reserved 615 These fields are unused. They MUST be initialized to zero by the 616 sender and MUST be ignored by the receiver. 618 Mobility Options 620 Variable-length field of such length that the complete Mobility 621 Header is an integer multiple of 8 octets long. This field 622 contains zero or more TLV-encoded mobility options. This document 623 does not define any new mobility option. The receiver MUST ignore 624 and skip any options which it does not understand. These mobility 625 option(s) are used by the receiving mobility entity to identify 626 the specific binding or bindings that the sending mobility entity 627 requesting to be revoked. 629 The following options are valid in a Binding Revocation Indication: 631 o Home Network Prefix option [RFC5213]. This option MAY be used 632 when the (P) bit is set. This option MUST be present when the BRI 633 is used to revoke a single PMIP binding cache entry. 635 o Mobile Node Identifier Option [RFC4283]. This option is mandatory 636 when the (P) bit is set. Additionally, if the (G) bit is set by 637 the mobile access gateway, this option carries the MAG identity. 639 o Binding Identifier mobility option [ID-MCoA]. This option is 640 mandatory if the sending mobility entity requests to terminate one 641 binding of a multi care-of addresses bindings for the same mobile 642 node. The sending mobility entity may include more than one of 643 the BID mobility options. 645 o IPv4 Home Address option which contains the mobile node home IPv4 646 address [RFC5555]. This option is included only when the IPv4 HoA 647 Binding only (V) bit is set. 649 o Alternate Care-of Address mobility option [RFC3775]. This option 650 MAY be included to indicate the Care-of Address of the mobile 651 node's binding that is being revoked. In the case when the Global 652 (G) bit set, this option identifies all the mobility bindings that 653 share the same care-of address. Additionally, if the Global (G) 654 bit set, more than one Alternate Care-of Address mobility options 655 MAY be present in the Binding Revocation Indication message. 657 If no options are present in this message, 4 octets of padding are 658 necessary and the Header Len field of the Binding Revocation Message 659 will be set to 1. 661 6.2. Binding Revocation Acknowledgement Message 663 The Binding Revocation Acknowledgement (BRA) message is a Binding 664 Revocation Message which has a MH type and a Binding 665 Revocation Type value of 2. It is used to acknowledge the receipt of 666 a Binding Revocation Indication message described in Section 6.1. 667 This packet is sent as described in Section 9.2.2, Section 10.1.2, 668 and Section 11.2. 670 When the value 2 is indicated in the Binding Revocation type field of 671 the Binding Revocation Message, the format of the Binding Revocation 672 Message Data follows the Binding Revocation Acknowledgement message 673 as in Figure 6 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | B.R. Type = 2 | Status | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Sequence # |P|V|G| Reserved | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 . . 683 . Mobility options . 684 . . 685 | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 6: Binding Revocation Acknowledgement Message 690 Status 692 8-bit unsigned integer indicating the result of processing the 693 Binding Revocation Indication message by the receiving mobility 694 entity. Values of the Status field less than 128 indicate that 695 the Binding Revocation Indication was processed successfully by 696 the receiving node. Values greater than or equal to 128 indicate 697 that the Binding Revocation Indication was rejected by the 698 receiving node. The following status values are currently 699 defined: 701 0 success 702 1 partial success 703 128 Binding Does NOT Exist 704 129 IPv4 Home Address Option Required 705 130 Global Revocation NOT Authorized 706 131 Revoked Mobile Nodes Identity Required 707 132 Revocation Failed - MN is Attached 708 133 Revocation Trigger NOT Supported 709 134 Revocation Function NOT Supported 711 Sequence # 713 The sequence number in the Binding Revocation Acknowledgement is 714 copied from the Sequence Number field in the Binding Revocation 715 Indication. It is used by the revoking mobility entity, e.g., HA, 716 LMA, MAG, in matching this Binding Revocation Acknowledgement with 717 the outstanding Binding Revocation Indication. 719 Proxy Binding (P) 721 The Proxy Binding (P) bit is set if the (P) bit is set in the 722 corresponding Binding Revocation Indication message. 724 IPv4 HoA Binding Only (V) 726 The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in 727 the corresponding Binding Revocation Indication message. 729 Global (G) 731 The Global (G) bit is set if the (G) bit is set in the 732 corresponding Binding Revocation Indication message. 734 Reserved 736 These fields are unused. They MUST be initialized to zero by the 737 sender and MUST be ignored by the receiver. 739 Mobility Options 741 Variable-length field of such length that the complete Mobility 742 Header is an integer multiple of 8 octets long. This field 743 contains zero or more TLV-encoded mobility options. In the case 744 when the Status field is set to success, no mobility option is 745 required. The mobility option(s) is usually used to communicate 746 information of the bindings that failed the revocation procedure. 748 The following mobility options are valid in a Binding Revocation 749 Acknowledgement: 751 o Home Network Prefix option [RFC5213]. This option MAY be included 752 when the (P) bit is set. 754 o Mobile Node Identifier Option [RFC4283]. This option MAY be 755 included when the (P) bit is set. This option SHOULD be included 756 if the Home Network Prefix option is included. 758 o Binding Identifier mobility option [ID-MCoA]. This option MAY be 759 included to indicate the specific BID that the receiving node 760 failed to revoke. 762 If no options are present in this message, 4 octets of padding are 763 necessary and the Header Len field of the Binding Revocation Message 764 will be set to 1. 766 7. Binding Revocation Process Operation 768 The following subsections describe the details of the binding 769 revocation generic process by the different mobility entities. 771 7.1. Sending Binding Revocation Messages 773 When sending a Binding Revocation message, the sending mobility node, 774 initiator, constructs the packet as it would any other Mobility 775 Header with the exception of setting the MH Type field to . 777 In addition, the mobility entity which initiates the binding 778 revocation process by sending a Binding Revocation Indication 779 message, initiator, MUST construct the Binding Revocation Message 780 Data following the format of the Binding Revocation Indication 781 message as described in Section 6.1. In the BRI message, the 782 initiator MUST set the Sequence Number field to the next sequence 783 number available for Binding Revocation. Since sending Binding 784 Revocation Indication message is not done on a regular basis, a 16 785 bit sequence number field is large enough to allow the initiator to 786 match the Binding Revocation Acknowledgement to the outstanding 787 Binding Revocation Indication with (A) bit set using the sequence 788 number field only. 790 However, when the responder acknowledges the Binding Revocation 791 Indication message, the responder MUST constructs the Binding 792 Revocation message packet as it would any other Mobility Header with 793 the exception of setting the MH Type field to . It also 794 MUST construct the Binding Revocation Message Data following the 795 format of the Binding Revocation Acknowledgement message as described 796 in Section 6.2. In this case, the responder MUST set the Sequence 797 Number field by copying the value from the Sequence Number field of 798 the received Binding Revocation Indication. Additionally, it MUST 799 set the status field to a valid value that reflects the processing of 800 the received Binding Revocation Indication. 802 A mobility entity MUST secure Binding Revocation Indication and 803 Binding Revocation Acknowledgement messages with the same underlying 804 security association, e.g., IPsec SA, that has been used to secure 805 the mobile node binding registration signaling. 807 7.2. Receiving Binding Revocation Messages 809 When receiving a Binding Revocation message, the receiving mobility 810 node MUST verify the Mobility Header as described in section 9.2. of 812 [RFC3775]. If the packet is dropped due to failing any of the 813 Mobility Headers test check, the receiving node MUST follow the 814 processing rules as in Section 9.2 of [RFC3775]. If the receiving 815 node does not support the Binding Revocation Indication message and 816 does not recognize the new MH type, it sends a Binding Error message 817 with the Status field set to 2 as described in [RFC3775]. 819 Since some mobility entities, e.g., local mobility anchor and mobile 820 access gateway, are allowed to receive and possibly send a Binding 821 Revocation Indication or Binding Revocation Acknowledgement for 822 different cases, therefore, if IPsec is used to secure signaling 823 between the local mobility anchor and mobile access gateway, it 824 prevents any of them from processing a Binding Revocation message 825 that was not constructed by an authorized party. 827 Upon receiving a packet carrying a Binding Revocation Indication or 828 Binding Revocation Acknowledgement, the receiving mobility entity 829 verifies that the packet was received protected with the security 830 association that has been used during the binding registration 831 signaling phase, e.g., an IPsec SA. 833 Upon receiving a packet carrying a Binding Revocation 834 Acknowledgement, the receiving mobility entity, initiator, MUST 835 validate that sequence number in the Sequence Number field matches 836 the sequence number of an outstanding Binding Revocation Indication 837 that was sent by the initiator. If the sequence number does not 838 match any sequence number of any of the outstanding Binding 839 Revocation Indication, the receiving node MUST silently discard the 840 message but MAY log the event. 842 If a mobility node receives a Binding Revocation Indication message 843 with the Revocation Trigger field is set to a value that NOT 844 supported, the receiving mobility node SHOULD reject the Binding 845 Revocation Indication message by sending a Binding Revocation 846 Acknowledgement message with the Status field set to "Revocation 847 Trigger NOT Supported". 849 If a mobility node receives a Binding Revocation Indication message 850 with a Revocation Trigger value that is NOT in line with the Binding 851 Revocation Indication message intent, e.g., the Global Revocation (G) 852 bit set and the Revocation Trigger field vale is a per-MN specific, 853 the receiving mobility node SHOULD reject the Binding Revocation 854 Indication message by sending a Binding Revocation Acknowledgement 855 message with the Status field set to "Revocation Function NOT 856 Supported". 858 7.3. Retransmission of Binding Revocation Indication 860 If the sending mobility entity does not receive a Binding Revocation 861 Acknowledgement in response to the outstanding initial Binding 862 Revocation Indication before the InitMINDelayBRIs timer expires, the 863 mobility entity, e.g. LMA, SHOULD retransmit the same BRI message up 864 to the BRIMaxRetriesNumber as defined in Section 12. 866 The retransmissions by the sending mobility entity MUST use an 867 exponential back-off process in which the timeout period is doubled 868 upon each retransmission, until either the node receives a response 869 or the timeout period reaches the value MAX_BRACK_TIMEOUT. The 870 sending mobility entity MAY continue to send these messages at this 871 slower rate up to the BRIMaxRetriesNumber. 873 If the revoking mobility entity does not receive a Binding Revocation 874 Acknowledgement message after the maximum number of retransmits have 875 been sent, the revoking mobility entity can clean the mobile node 876 binding cache and all resources associated with this binding. The 877 revoking mobility entity may log the event. 879 8. Home Agent Operation 881 8.1. Sending Binding Revocation Indication 883 To terminate a mobile node registration and its current binding with 884 the home agent, the home agent sends a packet to the mobile node 885 containing a Binding Revocation Indication, with the packet 886 constructed as follows: 888 o The Acknowledge (A) bit MAY be set to request the mobile node to 889 send a Binding Revocation Acknowledgement upon receipt of the 890 Binding Revocation Indication. 892 o The Revocation Trigger field MUST be set to indicate to the mobile 893 node the reason for revoking its IP mobility binding with the home 894 agent. The Revocation Trigger may be used by the mobile node to 895 take further steps if necessary. 897 o The Binding Revocation Indication MUST be sent using a Type 2 898 routing header which contains the mobile node's registered IPv6 899 home address for the binding being revoked. 901 o The care-of address for the binding MUST be used as the 902 destination address in the packet's IPv6 header, unless an 903 Alternate Care-of Address mobility option is included in the 904 Binding Revocation Indication. 906 o If the home agent needs to only revoke the mobile node's IPv4 home 907 address binding, the home agent MUST set the IPv4 HoA Binding Only 908 (V) bit and MUST include the mobile node's registered IPv4 home 909 address that is being revoked in the IPv4 Home Address option. 911 The Acknowledge (A) bit in the Binding Revocation Indication requests 912 the mobile node to return a Binding Revocation Acknowledgement in 913 response to this Binding Revocation Indication. As described in 914 Section 7.3, the home agent SHOULD retransmit this Binding Revocation 915 Indication to the mobile node before terminating its IP connection 916 until it receives a matching Binding Revocation Acknowledgement or 917 the BRIMaxRetransmitNumber has been reached. 919 When the home agent sends a Binding Revocation Indication to the 920 mobile node with the (A) bit set, the home agent sets a flag in the 921 mobile node BCE to indicate that revocation is in progress and starts 922 the InitMINDelayBRIs timer. The home agent maintains the mobile node 923 BCE in this state until it receives a Binding Revocation 924 Acknowledgement or retransmits the Binding Revocation Indication 925 message as described in Section 7.3. 927 In a race condition case, the home agent may receive a Binding Update 928 from the mobile node while the mobile node's BCE has the revocation 929 in progress flag set, the home agent SHOULD handle this case based on 930 the reason for sending the Binding Revocation Indication message and 931 its local policy. In this case, if the home agent accepts the 932 Binding Update, it needs to update the mobile node BCE accordingly, 933 e.g. removing the revocation in progress flag. 935 When the home agent needs to revoke one or more of a mobile node 936 bindings that were created using Multi Care-of address registration 937 as in [ID-MCoA], the home agent MUST include all the related BID 938 mobility options that identify these bindings in the Binding 939 Revocation Indication message. In the case when the home agent needs 940 to revoke all of the mobile node bindings, the home agent SHOULD NOT 941 include any of the BID mobility options. 943 8.2. Receiving Binding Revocation Acknowledgement 945 When the home agent receives a packet carrying a valid Binding 946 Revocation Acknowledgement that was successfully processed as in 947 Section 7.2, the home agent SHOULD examine the Status field as 948 follows: 950 o If the Status field indicates that the Binding Revocation 951 Indication was processed successfully, the home agent deletes the 952 current timer and the mobile node bindings and all related 953 resources. 955 o If the Status field indicates any value other than success, the 956 home agent SHOULD examine any mobility options included in the 957 Binding Revocation Acknowledgement. The home agent MAY log the 958 appropriate event to reflect the received status. 960 9. Local Mobility Anchor Operation 962 9.1. Binding Revocation Initiator 964 9.1.1. Sending Binding Revocation Indication 966 To terminate a mobile node PMIPv6 registration and its current 967 binding with the local mobility anchor, the local mobility anchor 968 sends a packet to the mobile access gateway containing a Binding 969 Revocation Indication message following the procedure in Section 7.1 970 and the following rules: 972 o The Acknowledge (A) bit MAY be set to request the mobile access 973 gateway to send a Binding Revocation Acknowledgement upon receipt 974 of the Binding Revocation Indication. 976 o The Proxy Mobile IP (P) bit MUST be set to indicate that the 977 binding being revoked is a PMIPv6 binding. 979 o The Revocation Trigger field MUST be set to indicate to the mobile 980 access gateway the reason for removing the specified mobile node 981 PMIPv6 binding at the local mobility anchor. The Revocation 982 Trigger may be used by the mobile access gateway to learn the 983 mobile node's latest movement. 985 o In case of revoking all Per-Peer bindings, the Global (G) bit MUST 986 be set and the Revocation Trigger MUST contain a value of "Per- 987 Peer Policy" to request the mobile access gateway to remove all 988 Per-Peer bindings that are registered with the local mobility 989 anchor and hosted at this mobile access gateway. 991 o Whenever the Global (G) bit is set in the Binding Revocation 992 Indication, the Acknowledge (A) bit MUST be set to request the 993 mobile access gateway to send a Binding Revocation 994 Acknowledgement. 996 o The packet MUST contain the Mobile Node Identifier, MN-ID, option 997 which contains the mobile node's NAI that was used in the Proxy 998 Binding Update during the mobile node registration. 1000 o If the Mobile Node Identifier, MN-ID, is registered in more than 1001 one of the mobile node's BCE and the local mobility anchor does 1002 NOT need to revoke all of the mobile node's bindings, the packet 1003 MUST contain another identifier to uniquely identify the mobile 1004 node binding(s) that is being revoked, e.g., at least one Home 1005 Network Prefix option which contains the mobile node's registered 1006 HNP for the binding being revoked. 1008 o The care-of address for the binding MUST be used as the 1009 destination address in the packet's IPv6 header, unless an 1010 Alternate Care-of Address mobility option is included in the 1011 Binding Revocation Indication message. 1013 The Acknowledge (A) bit in the Binding Revocation Indication requests 1014 the mobile access gateway to return a Binding Revocation 1015 Acknowledgement. As described in Section 7.3, the local mobility 1016 anchor SHOULD retransmit this Binding Revocation Indication before 1017 deleting the mobile node IP tunnel to the mobile access gateway until 1018 it receives a matching Binding Revocation Acknowledgement or the 1019 BRIMaxRetransmitNumber is reached. The local mobility anchor MAY 1020 delete the mobile node(s) IP tunnel immediately after sending the 1021 Binding Revocation Indication and before receiving the Binding 1022 Revocation Acknowledgement message. 1024 When the local mobility anchor sends a Binding Revocation Indication 1025 to the mobile access gateway to remove a specific binding and the 1026 Acknowledge (A) bit is set, the local mobility anchor sets a flag in 1027 the mobile node proxy BCE to indicate that revocation is in progress 1028 and starts the InitMINDelayBRIs timer. The local mobility anchor 1029 SHOULD maintain the mobile node proxy BCE in this state until it 1030 receives a Binding Revocation Acknowledgement or the 1031 BRIMaxRetransmitNumber is reached. In the case when the local 1032 mobility anchor sets the Revocation Trigger field to a value which 1033 indicates inter-MAG handover, the local mobility anchor MAY switch 1034 the mobile node IP tunnel to the target mobile access gateway before 1035 sending the Binding Revocation Indication to the source mobile access 1036 gateway. 1038 In a race condition case, the local mobility anchor may receive a 1039 Proxy Binding Update from the mobile access gateway while the mobile 1040 node's proxy BCE has the revocation in progress flag set, the local 1041 mobility anchor should handle this case based on the reason for 1042 sending the Binding Revocation Indication message and its local 1043 policy. In this case, if the local mobility anchor accepts the Proxy 1044 Binding Update, it needs to update the mobile node proxy BCE 1045 accordingly, e.g. removing the revocation in progress flag. 1047 When the local mobility anchor needs to revoke all mobile nodes proxy 1048 BCE that are registered with the local mobility anchor and hosted at 1049 the mobile access gateway, it MUST set the Global (G) bit and set the 1050 value of the Revocation Trigger field to "Per-Peer Policy". In this 1051 case, the local mobility anchor MUST NOT include any mobility options 1052 in the this Binding Revocation Indication message. 1054 When the local mobility anchor needs to revoke all mobile nodes proxy 1055 BCE that belong to a specific realm, e.g. @example.com, that are 1056 registered with the local mobility anchor and hosted at the mobile 1057 access gateway, the local mobility anchor MUST set the Global (G) bit 1058 and set the value of the Revocation Trigger field to "Revoking 1059 Mobility Node Local Policy". In this case, the local mobility anchor 1060 MUST include a mobility option in the Binding Revocation Indication 1061 to identify the impacted bindings, e.g., MN-ID option with an NAI 1062 value of @example.com, to identify all the mobile nodes BCEs that 1063 have a MN-ID with a realm that matches the NAI value in the received 1064 MN-ID option and need to be removed. 1066 When the mobile node is registered with multiple Home Network 1067 Prefixes for the same proxy care-of address, the local mobility 1068 anchor SHOULD include a HNP option for each registered HNP in the 1069 Binding Revocation Indication. Alternatively, it MAY include only 1070 the mobile node identifier, MN-ID, option to indicate to the mobile 1071 access gateway to remove all bindings of the specified mobile node 1072 NAI in the MN-ID option. 1074 According to Proxy Mobile IPv6 specification [RFC5213], if the local 1075 mobility anchor receives a Proxy Binding Update message from a new 1076 mobile access gateway for extending the binding lifetime of the only 1077 BCE of this mobile node with the Handoff Indicator value is set to 1078 "Inter-MAG Handover - Unknown", the local mobility anchor waits a 1079 period of MaxDelayBeforeNewBCEAssign to receive a de-registration 1080 message from the previous mobile access gateway before updating the 1081 mobile node's BCE with the new point of attachment. If a de- 1082 registration message is not received,, the local mobility anchor 1083 considers the received Proxy Binding Update message as a request for 1084 a new BCE and if processed successfully, the local mobility anchor 1085 assigns a different HNP for the new BCE. 1087 This document updates the local mobility anchor's behavior in this 1088 case. If the local mobility anchor supports the binding revocation 1089 mechanism as described in this document, it SHOULD proactively send a 1090 Binding Revocation Indication message to the previous mobile access 1091 gateway instead of waiting for a de-registration from the previous 1092 mobile access gateway. In the Binding Revocation Indication message, 1093 the (A) bit MUST be set and the Revocation Trigger MUST be set to 1094 "Inter-MAG Handover - Unknown". 1096 If the local mobility anchor sent a Binding Revocation Indication 1097 message with the Revocation Trigger field set to "Inter-MAG Handover 1098 - Unknown" and while waiting for a Binding Revocation Acknowledgement 1099 response, the following are possible conditions that the local 1100 mobility anchor MUST handle as specified below: 1102 o If the local mobility anchor receives a successful Binding 1103 Revocation Acknowledgement message or a de-registration message 1104 from the previous mobile access gateway, the local mobility anchor 1105 MUST update the mobile node BCE in a similar way as if it received 1106 a de-registration message as described in [RFC5213]. 1108 o If the local mobility anchor receives a Binding Revocation 1109 Acknowledgement message with the status field set to "Revocation 1110 Failed - MN is Attached", the local mobility anchor SHOULD update 1111 the mobile node BCE in a similar way as if it did NOT receive a 1112 de-registration before the MaxDelayBeforeNewBCEAssign timer 1113 expires by creating a new BCE as described in [RFC5213]. 1115 o If the local mobility anchor did not receive a Binding Revocation 1116 Acknowledgement message nor a de-registration Proxy Binding Update 1117 from the previous mobile access gateway after it exhausted all of 1118 the Binding Revocation Indication message retransmissions as 1119 described in Section 7.3, the local mobility anchor SHOULD update 1120 the mobile node's BCE in a similar way as if it did NOT receive a 1121 de-registration before the MaxDelayBeforeNewBCEAssign timer 1122 expires by creating a new BCE as described in [RFC5213]. Note 1123 that the local mobility anchor SHOULD use the recommended number 1124 of retransmissions for the Binding Revocation Indication message 1125 as described in Section 12 to avoid delaying the creation of a new 1126 binding cache entry for too long, if the mobile node is actually 1127 attaching to the new MAG with a different interface. 1129 When the mobile node is registered with an IPv4 proxy home address in 1130 addition to the Home Network Prefix where both of the IPv4 pHoA and 1131 HNP are bound to the same proxy CoA, the local mobility anchor MAY 1132 revoke the mobile node IPv4 proxy HoA binding to the current mobile 1133 node proxy CoA while maintaining the mobile node binding of the HNP 1134 to its current pCoA as part of the mobile node BCE. In this case, if 1135 the local mobility anchor decides to revoke the mobile node IPv4 1136 proxy HoA ONLY, it MUST send a Binding Revocation Indication message 1137 following the procedure in Section 7.1 and the following rules: 1139 o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to 1140 indicate that only the IPv4 home address binding is being revoked. 1142 o The Acknowledge (A) bit MUST be set to request the mobile access 1143 gateway to send a Binding Revocation Acknowledgement message. 1145 o The IPv4 Home Address option MUST be included with the mobile 1146 node's registered IPv4 home address that is being released in 1147 addition to the MN-ID option. 1149 o The mobile node Home Network Prefix option MUST NOT be included. 1151 o The Revocation Trigger field MUST be set to an appropriate value, 1152 e.g. "User Initiated Session(s) Termination". 1154 9.1.2. Receiving Binding Revocation Acknowledgement 1156 When the local mobility anchor receives a packet carrying a valid 1157 Binding Revocation Acknowledgement that was successfully processed as 1158 in Section 7.2 and if the mobile node BCE is in the state of 1159 Revocation in progress, the local mobility anchor SHOULD examine the 1160 Status field before clearing the mobile node related resources as 1161 follows: 1163 o If the Status field indicates that the BRI was processed 1164 successfully, the local mobility anchor delete the current timer 1165 and the mobile node proxy bindings and all associated resources. 1167 o If the Status field indicates partial success value or MN binding 1168 does not exist, the local mobility anchor SHOULD examine mobility 1169 options that are included in the Binding Revocation 1170 Acknowledgement, if any, before deleting the current timer and the 1171 mobile node associated proxy bindings and other related resources. 1172 It is based on the local mobility anchor local policy how to 1173 handle the mobile node BCE(s) that the mobile access gateway 1174 indicated it failed the revocation procedure, however, the LMA MAY 1175 log the event. 1177 9.2. Binding Revocation Responder 1179 9.2.1. Receiving Binding Revocation Indication 1181 When the local mobility anchor receives a packet carrying a Binding 1182 Revocation Indication that was successfully processed as in 1183 Section 7.2, the local mobility anchor SHOULD in addition process the 1184 message as follows: 1186 o Binding Revocation Indication is formatted as in Section 6.1 and 1187 if the (P) bit is set, the local mobility anchor MUST validate 1188 that all impacted binding(s) have the proxy binding flag set. 1190 o If the Global (G) bit is set and the Revocation Trigger value is 1191 "Per-Peer Policy", the Proxy (P) bit MUST be set and the Binding 1192 Revocation Indication SHOULD contain the mobile access gateway ID 1193 in the MN-ID option. The local mobility anchor MUST verify that 1194 the identified mobile access gateway as per the value in the MN-ID 1195 option is authorized to use the Global revocation. The mechanism 1196 the local mobility anchor uses to verify the mobile access gateway 1197 authorization is out of scope of this document. 1199 o If the Global (G) bit is set and the Revocation Trigger value is 1200 "Per-Peer Policy", and only the mobile node identifier, MN-ID, 1201 option is included, the local mobility anchor MUST revoke all 1202 mobile nodes bindings which proxy CoA is the one used as the 1203 source of the IPv6 packet that carried the Binding Revocation 1204 Indication. However, if one or more Alternate Care-of Address 1205 options are included in addition to the mobile node identifier 1206 option, the local mobility anchor MUST revoke all mobile nodes 1207 bindings which proxy Care-of Address matches one of the Care-of 1208 address(es) in the Alternate Care-of Address option(s). 1210 o The local mobility anchor identifies all impacted mobile nodes 1211 bindings and if the Acknowledgement (A) bit is set, the local 1212 mobility anchor MUST send a Binding Revocation Acknowledgement 1213 following Section 9.2.2 using the appropriate status code. 1215 o If the Global (G) bit is NOT set, the local mobility anchor SHOULD 1216 use the included mobility options to identify the impacted mobile 1217 node binding as follows: 1219 1. If only the mobile node identifier, MN-ID, option is included, 1220 the local mobility anchor MUST revoke all bindings for this 1221 mobile node which use the specified mobile node NAI. 1223 2. If the mobile node identifier, MN-ID, and the Home Network 1224 Prefix option are included, the local mobility anchor MUST 1225 only remove the specified proxy binding. 1227 3. If the mobile node identifier, MN-ID, option and more than one 1228 Home Network Prefix options are included, the local mobility 1229 anchor MUST remove all bindings which are referenced by these 1230 multiple Home Network Prefixes for the specified mobile node 1231 NAI. 1233 The Revocation Trigger field value in the received Binding Revocation 1234 Indication could be used by the local mobility anchor to log an event 1235 or update some local parameters which tracks the state of the peer 1236 mobile access gateway. 1238 9.2.2. Sending Binding Revocation Acknowledgement 1240 When the local mobility anchor receive a valid Binding Revocation 1241 Indication with the (A) bit set and after processing the Binding 1242 Revocation Indication message, the local mobility anchor sends a 1243 packet to the mobile access gateway containing a Binding Revocation 1244 Acknowledgement following the process in Section 7.1 and the 1245 following: 1247 o If the (P) bit was set in the received Binding Revocation 1248 Indication, the local mobility anchor MUST set the (P) bit in the 1249 Binding Revocation Acknowledgement. 1251 o If the Global (G) bit was set in the received Binding Revocation 1252 Indication, the local mobility anchor MUST set the (G) bit in the 1253 Binding Revocation Acknowledgement. 1255 o If the IPv4 HoA Binding Only (V) bit was set in the received 1256 Binding Revocation Indication, the local mobility anchor MUST set 1257 the (V) bit in the Binding Revocation Acknowledgement. 1259 o The local mobility anchor MUST set the Status field to a valid 1260 code that reflects the processing of the received Binding 1261 Revocation Indication. If the mobile access gateway is not 1262 authorized to use the Per-Peer Global revocation feature, the 1263 local mobility anchor MUST set the Status field to (Global 1264 Revocation NOT Authorized). 1266 o In the case that one of the bindings identified in the received 1267 Binding Revocation Indication message has already been released 1268 before receiving the it, the local mobility anchor MAY set the 1269 Status field to partial success and in this case it MAY include 1270 the mobile node identifier or the Home Network Prefix option to 1271 identify the binding(s) that failed revocation. 1273 o The destination IP address of the IPv6 packet of the Binding 1274 Revocation Acknowledgement is set to the source IP address of the 1275 received Binding Revocation Indication. 1277 10. Mobile Access Gateway Operation 1279 10.1. Binding Revocation Responder 1281 10.1.1. Receiving Binding Revocation Indication 1283 Upon receiving a packet carrying a Binding Revocation Indication, the 1284 mobile access gateway MUST validate the packet according to 1285 Section 7.2 and the following: 1287 o Binding Revocation Indication MUST be formatted as in Section 6.1 1288 and the (P) bit is set. 1290 o If the Acknowledgement (A) bit in the received Binding Revocation 1291 Indication is set, the mobile access gateway MUST send a Binding 1292 Revocation Acknowledgement following Section 10.1.2 using the 1293 appropriate status value. 1295 o If the Global (G) bit is set and the Revocation Trigger field 1296 value is "Per-Peer policy", the mobile access gateway identifies 1297 all bindings that are registered at the local mobility anchor and 1298 hosted at the mobile access gateway. This Binding Revocation 1299 Indication does not include any other mobility options. In this 1300 case, the mobile access gateway MUST send a Binding Revocation 1301 Acknowledgement with the appropriate status code to the local 1302 mobility anchor. 1304 o If the Global (G) bit is set and the Revocation Trigger field 1305 value is "Revoking Mobility Node Local Policy", the mobile access 1306 gateway MUST identify all bindings that are registered at the 1307 local mobility anchor and hosted at the mobile access gateway 1308 using the mobility option(s) included in the Binding Revocation 1309 Indication which SHOULD include at least the MN-ID option, e.g., 1310 with a wild card NAI. In this case, the mobile access gateway 1311 MUST send a Binding Revocation Acknowledgement with the 1312 appropriate status code to the local mobility anchor. 1314 o If the Global (G) bit is set and the Revocation Trigger field 1315 value is "Revoking Mobility Node Local Policy", and no mobility 1316 options are included in the Binding Revocation Indication message 1317 or the mobile access gateway is not able to identify the impacted 1318 mobile nodes bindings based on the included mobility options, the 1319 mobile access gateway MUST treat this as an error scenario. In 1320 this case, the mobile access gateway SHOULD send a Binding 1321 Revocation Acknowledgement message with status "Revoked Mobile 1322 Nodes Identity Required". 1324 o If the Revocation Trigger field value in the received Binding 1325 Revocation Indication message indicates inter-MAG handover, e.g., 1326 Inter-MAG Handover - Unknown, and the (A) bit is set, the mobile 1327 access gateway use the mobility option(s) included in the Binding 1328 Revocation Indication message to identify the mobile node binding. 1329 The mobile access gateway SHOULD validate that the mobile node is 1330 no longer attached to the mobile access gateway before sending a 1331 successful Binding Revocation Acknowledgement message to the local 1332 mobility anchor. However, if the mobile access gateway verified 1333 that the mobile node is still directly attached, the mobile access 1334 gateway MUST set the status field in the Binding Revocation 1335 Acknowledgement to "Revocation failed - MN is Attached". 1337 o If the IPv4 HoA Binding Only (V) bit in the received Binding 1338 Revocation Indication message is set, the mobile access gateway 1339 uses the MN-ID option to identify the mobile node binding entry in 1340 the BUL. It MUST verify that the IPv4 address included in the 1341 IPv4 Home Address option in the received Binding Revocation 1342 Indication is the same as the IPv4 proxy HoA that is assigned to 1343 the mobile node. After the mobile access gateway successfully 1344 validates the received IPv4 home address as the mobile node IPv4 1345 HoA, it MUST consider this as an indication to release the mobile 1346 node IPv4 proxy HoA binding to the mobile node current proxy CoA 1347 ONLY. Consequently, it MUST continue to maintain the mobile node 1348 IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA 1349 as part of the mobile node binding in the BUL entry and release 1350 all resources associated with the MN IPv4 proxy HoA binding to the 1351 MN pCoA. In this case, the mobile access gateway MUST send a 1352 Binding Revocation Acknowledgement message with the Status field 1353 is set to success. On the other hand, if the mobile access 1354 gateway is able to identify the mobile node binding using the 1355 MN-ID but failed to identify the received IPv4 proxy HoA, it MUST 1356 send a Binding Revocation Acknowledgement with Status field is set 1357 to "Binding Does NOT Exist". 1359 The Revocation Trigger field value in the received Binding Revocation 1360 Indication could be used by the mobile access gateway to define what 1361 actions the mobile access gateway could do to inform the mobile node 1362 that its IP connectivity to the current HNP has been terminated, 1363 e.g., if the Revocation Trigger field is set to "Administrative 1364 Reason", the mobile access gateway may send a RA message after 1365 setting the Home Network Prefix valid lifetime to zero. 1367 10.1.2. Sending Binding Revocation Acknowledgement 1369 When the mobile access gateway receive a valid Binding Revocation 1370 Indication with the (A) bit set and after processing it, the mobile 1371 access gateway sends a packet to the local mobility anchor containing 1372 a Binding Revocation Acknowledgement according to the procedure in 1373 Section 7.1 and the following: 1375 o The mobile access gateway MUST set the (P) bit in the Binding 1376 Revocation Acknowledgement if it is set in the received Binding 1377 Revocation Indication. 1379 o If the Global (G) bit was set in the received Binding Revocation 1380 Indication, the mobile access gateway MUST set the (G) bit in the 1381 Binding Revocation Acknowledgement. 1383 o If the IPv4 HoA Binding Only (V) bit was set in the received 1384 Binding Revocation Indication, the mobile access gateway MUST set 1385 the (V) bit in the Binding Revocation Acknowledgement. 1387 o The mobile access gateway MUST set the Status field to a valid 1388 code that reflects the processing of the received Binding 1389 Revocation Indication. 1391 o In the case that one or more of the bindings identified in the 1392 received Binding Revocation Indication message has already been 1393 released before receiving the Binding Revocation Indication, the 1394 mobile access gateway MAY set the Status field to "partial 1395 success" and include the mobile node identifier, MN-ID, or the 1396 Home Network Prefix option to identify the binding(s) that failed 1397 to be removed as part of the revocation procedure. 1399 o The destination IP address of the IPv6 packet of the Binding 1400 Revocation Acknowledgement is set to the source IP address of the 1401 received Binding Revocation Indication. 1403 10.2. Binding Revocation Initiator 1405 10.2.1. Sending Binding Revocation Indication 1407 The mobile access gateway could send a Binding Revocation Indication 1408 message to indicate the termination of multiple mobile node bindings, 1409 e.g., when using the global revocation with the Global (G) bit set. 1410 In this case when an event occurs which requires the mobile access 1411 gateway to inform the local mobility anchor to terminate all mobile 1412 nodes bindings which are registered at the local mobility anchor and 1413 the mobile access gateway, the mobile access gateway sends a Binding 1414 Revocation Indication message following Section 7.1 and the 1415 following: 1417 o The Acknowledge (A) bit MUST be set in the to request the local 1418 mobility anchor to send a Binding Revocation Acknowledgement upon 1419 receipt of the Binding Revocation Indication. 1421 o The Proxy Binding (P) bit MUST be set to indicate that bindings 1422 that being revoked is a PMIPv6 binding. 1424 o The Global (G) bit MUST be set and the Revocation Trigger MUST 1425 contain a value of "Per-Peer Policy" in the Binding Revocation 1426 Indication to request the local mobility anchor to remove all Per- 1427 Peer bindings that are registered with the local mobility anchor 1428 and hosted at this mobile access gateway. In this case, the MN-ID 1429 option MUST be included in the Binding Revocation Indication and 1430 contain the mobile access gateway identity. In addition, the 1431 mobile access gateway MAY include one or more Alternate Care-of 1432 Address option(s). The Alternate Care-of Address option(s) 1433 contain the proxy Care-of address(es) which their bindings are 1434 being impacted by this Binding Revocation Indication message. 1436 o The mobile access gateway address MAY be used as the source 1437 address in the packet's IPv6 header. 1439 The Acknowledge (A) bit in the Binding Revocation Indication requests 1440 the local mobility anchor to return a Binding Revocation 1441 Acknowledgement in response to this Binding Revocation Indication. 1442 As described in Section 7.3, the mobile access gateway SHOULD 1443 retransmit this Binding Revocation Indication to the local mobility 1444 anchor until it receives a matching Binding Revocation 1445 Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile 1446 access gateway MAY delete the mobile nodes IP tunnels immediately 1447 after sending the Binding Revocation Indication and before receiving 1448 a Binding Revocation Acknowledgement message from the LMA. 1450 10.2.2. Receiving Binding Revocation Acknowledgement 1452 When the mobile access gateway receives a packet carrying a valid 1453 Binding Revocation Acknowledgement that was successfully processed 1454 according to Section 7.2, the mobile access gateway MUST process the 1455 received Binding Revocation Acknowledgement as per the followings: 1457 o When the mobile access gateway receives a packet carrying a valid 1458 Binding Revocation Acknowledgement and the Global (G) and Proxy 1459 Binding (P) bits are set and the mobile nodes BCEs are in the 1460 state of Revocation in Progress, the mobile access gateway SHOULD 1461 examine the Status field as follows: 1463 o If the Status field indicates that the Binding Revocation 1464 Indication was processed successfully, the mobile access gateway 1465 delete the current timer and the mobile nodes proxy bindings and 1466 all associated resources. 1468 o If the Status field indicates (Global Revocation NOT Authorized), 1469 the mobile access gateway is not authorized to participate in a 1470 Per-Peer Global Revocation. The mobile access gateway SHOULD NOT 1471 retry sending a Binding Revocation Indication with the Global (G) 1472 bit set to the same local mobility agent. The mobile access 1473 gateway should raise an alarm or log an event to indicate this 1474 rejection. 1476 11. Mobile Node Operation 1478 11.1. Receiving Binding Revocation Indication 1480 Upon receiving a packet carrying a Binding Revocation Indication, the 1481 mobile node MUST validate the packet according to Section 7.2 and the 1482 following tests: 1484 o The mobile node MUST verify that the IP address in the Type 2 1485 routing header is its Home Address and that its Binding Update 1486 List contains an entry for that Home Address. If one of the 1487 tests, fails the mobile node SHOULD silently discard the received 1488 Binding Revocation Indication message. 1490 o If the Acknowledgement (A) bit is set in the Binding Revocation 1491 Indication and its Binding Update List contains an entry for the 1492 IP address in the Type 2 routing header, the mobile node MUST send 1493 a Binding Revocation Acknowledgement. However, in all other cases 1494 when the (A) bit is set in the BRI, the mobile node SHOULD send a 1495 Binding Revocation Acknowledgement. In all cases, the mobile node 1496 MUST follow Section 11.2 and send a Binding Revocation 1497 Acknowledgement using the appropriate status code. 1499 o If the IPv4 HoA Binding Only (V) bit is set in the received BRI 1500 message, the mobile node MUST verify that there is an IPv4 Home 1501 Address option in the received Binding Revocation Indication and 1502 the IPv4 address included in the IPv4 Home Address option is the 1503 same as its IPv4 HoA that is assigned to the mobile node. If this 1504 verification is successful, the mobile node MUST consider this 1505 Binding Revocation Indication as an indication to release the 1506 mobile node IPv4 HoA binding ONLY to its current Care-of Address. 1508 Consequently, the mobile node MUST continue to maintain its IPv6 1509 HoA binding to the current CoA as part of the mobile node binding 1510 in the BUL entry and release all resources associated with the MN 1511 IPv4 HoA binding. In this case, the mobile node MUST send a 1512 Binding Revocation Acknowledgement message with the Status field 1513 is set to "success". On the other hand, if the IPv4 Home Address 1514 Option was NOT included in the received BRI with the (V) bit set, 1515 the MN SHOULD send a Binding Revocation Acknowledgement message 1516 with the Status field set to "IPv4 Home Address Option Required". 1517 Additionally, if the IPv4 HoA received in the IPv4 Home Address 1518 Option is NOT the one assigned to the mobile node, the mobile node 1519 SHOULD send a Binding Revocation Acknowledgement with the status 1520 field set to "Binding Does NOT Exist". 1522 o The mobile node MUST verify that the (P) bit in the Binding 1523 Revocation Indication is NOT set. If the (P) bit is set, the 1524 mobile node MUST silently discard the Binding Revocation 1525 Indication message. 1527 o If the mobile node has registered multiple care-of addresses with 1528 its home agent, the mobile node MUST verify which binding is being 1529 revoked by examining the content of the Binding Revocation 1530 Indication message. If the mobile node received a Binding 1531 Revocation Indication with a single or more than one BID options 1532 and its home address is included in the Type 2 routing header, the 1533 mobile node MUST consider all of the care-of address(es) 1534 binding(s), identified in the BID options, with this home address 1535 are being revoked. 1537 o If the mobile node has multi Care-of Address bindings with its 1538 home agent and received a Binding Revocation Indication, without 1539 any BID option included and its home address was included in the 1540 Type 2 routing header, the mobile node MUST consider all of its 1541 registered care-of addresses bindings with this home address are 1542 being revoked. 1544 The Revocation Trigger field value in the received Binding Revocation 1545 Indication could be used by the mobile node to define what action the 1546 mobile node could do to be able to register again and receive its IP 1547 mobility service, e.g., contacting its home operator. 1549 11.2. Sending Binding Revocation Acknowledgement 1551 When the mobile node receives a Binding Revocation Indication from 1552 its home agent, the mobile node processes the received Binding 1553 Revocation Indication as in Section 11.1. If the mobile node is 1554 required to send a Binding Revocation Acknowledgement message in 1555 response to the received Binding Revocation Indication, the mobile 1556 node sends a packet to its home agent containing a Binding Revocation 1557 Acknowledgement according to the procedure in Section 7.1 and the 1558 following: 1560 o The mobile node MUST set the Status field to an appropriate value. 1561 The mobile node sets the Status field to success to reflect that 1562 it has received the Binding Revocation Indication and acknowledge 1563 that its IP connectivity with its home agent has been revoked. 1565 o The destination IP address of the IPv6 packet of the Binding 1566 Revocation Acknowledgement is set to the source IP address of the 1567 received IPv6 packet of the Binding Revocation Indication. The 1568 Mobile Node MUST include its home address in the Home Address 1569 Destination Option. 1571 12. Protocol Configuration Variables 1573 Any mobility entity which is allowed to invoke the binding revocation 1574 procedure by sending a Binding Revocation Indication message SHOULD 1575 allow the following variables to be configured. 1577 BRI Maximum Number of Retries (BRIMaxRetriesNumber) 1579 This variable specifies the maximum Number of times a mobility 1580 entity can retransmit a Binding Revocation Indication message 1581 before receiving a Binding Revocation Acknowledgement message. 1582 The default value for this parameter is 1. 1584 Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) 1586 This variable specifies the initial delay timeout in seconds 1587 before the revoking mobility entity retransmits a BRI message. 1588 The default is 1 second but not less than 0.5 seconds. 1590 Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT) 1592 This variable specifies the maximum delay timeout in seconds 1593 before the revoking mobility entity retransmits a BRI message. 1594 The default is 2 seconds. 1596 13. IANA Considerations 1598 This specification defines a new Binding Revocation Message using a 1599 new Mobility Header Type , as described in Section 6. The 1600 new Mobility Header type value needs to be assigned from the same 1601 numbering space as allocated for the other Mobility Header types. 1603 This document also creates a new name space "Binding Revocation Type" 1604 which indicates the type of the binding revocation message. The 1605 current binding revocation message types are described in Section 6.1 1606 and Section 6.2, and are the following: 1608 0 Reserved 1609 1 Binding Revocation Indication 1610 2 Binding Revocation Acknowledgement 1611 All other values are reserved 1613 Future values of the Binding Revocation Type can be allocated using 1614 Standards Action or IESG Approval [RFC5226]. 1616 In addition, this document also creates a second new namespace for 1617 the Revocation Trigger which indicates the reason behind sending the 1618 Binding Revocation Indication message. The current Revocation 1619 Trigger values are described in Section 6.1, and are the following: 1621 Reserved and Per-MN Revocation Trigger Values: 1622 0 Reserved 1623 1 Unspecified 1624 2 Administrative Reason 1625 3 Inter-MAG Handover - same Access Type 1626 4 Inter-MAG Handover - different Access Type 1627 5 Inter-MAG Handover - Unknown 1628 6 User Initiated Session(s) Termination 1629 7 Access Network Session(s) Termination 1630 8 Possible Out-of Sync BCE State 1631 250-255 Reserved For Testing Purposes only 1632 All other values are Reserved 1634 Global Revocation Trigger Values: 1635 128 Per-Peer Policy 1636 129 Revoking Mobility Node Local Policy 1638 Future values of the Revocation Trigger can be allocated using 1639 Standards Action or IESG Approval [RFC5226]. 1641 Furthermore, this document creates a third new name space "Status 1642 Code" for the Status field in the Binding Revocation Acknowledgement 1643 message. The current values are described in Section 6.2, and are 1644 the following: 1646 0 success 1647 1 partial success 1648 128 Binding Does NOT Exist 1649 129 IPv4 Home Address Option Required 1650 130 Global Revocation NOT Authorized 1651 131 Revoked Mobile Nodes Identity Required 1652 132 Revocation Failed - MN is Attached 1653 133 Revocation Trigger NOT Supported 1654 134 Revocation Function NOT Supported 1656 Future values of the Status field can be allocated using Standards 1657 Action or IESG Approval [RFC5226]. 1659 All fields labeled "Reserved" are only to be assigned through 1660 Standards Action or IESG Approval. 1662 14. Security Considerations 1664 The protocol described here uses the same security association 1665 between the mobile node and the home agent or the mobile access 1666 gateway and the local mobility anchor that has been used to exchange 1667 the corresponding MIPv6 or PMIPv6 Binding Update and Binding 1668 Acknowledgement when the session was established. If IPsec is used, 1669 the SPD of this IPsec SA MUST allow the MH type for the Binding 1670 Revocation Message defined in this document. 1672 However, in the case when the mobile access gateway sends a Binding 1673 Revocation Indication message with the Global (G) bit is set and the 1674 Revocation Trigger field is set to "Per-Peer policy", the local 1675 mobility anchor MUST verify that the mobile access gateway is 1676 authorized to use Per-Peer Global Revocation. 1678 15. Acknowledgements 1680 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1681 Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay 1682 Devarapalli, and Joel Hortelius for their review and comments of this 1683 draft and all colleagues who have supported the advancement of this 1684 draft effort. 1686 16. References 1687 16.1. Normative References 1689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1690 Requirement Levels", BCP 14, RFC 2119, March 1997. 1692 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1693 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1694 May 2008. 1696 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1697 in IPv6", RFC 3775, June 2004. 1699 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1700 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1701 (MIPv6)", RFC 4283, November 2005. 1703 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1704 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1706 [ID-PMIP6-IPv4] 1707 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1708 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-10 1709 (work in progress), March 2009. 1711 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1712 "Multiple Care-of Addresses Registration", 1713 draft-ietf-monami6-multiplecoa-12 (work in progress), 1714 March 2009. 1716 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1717 Routers", RFC 5555, June 2009. 1719 16.2. Informative References 1721 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1722 August 2002. 1724 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1725 Mobile IPv4", RFC 3543, August 2003. 1727 Authors' Addresses 1729 Ahmad Muhanna 1730 Nortel 1731 2221 Lakeside Blvd. 1732 Richardson, TX 75082 1733 USA 1735 Email: amuhanna@nortel.com 1737 Mohamed Khalil 1738 Nortel 1739 2221 Lakeside Blvd. 1740 Richardson, TX 75082 1741 USA 1743 Email: mkhalil@nortel.com 1745 Sri Gundavelli 1746 Cisco Systems 1747 170 West Tasman Drive 1748 San Jose, CA 95134 1749 USA 1751 Email: sgundave@cisco.com 1753 Kuntal Chowdhury 1754 Startent Networks 1755 30 International Place 1756 Tewksbury, MA 01876 1757 USA 1759 Email: kchowdhury@starentnetworks.com 1761 Parviz Yegani 1762 Juniper Networks 1763 1194 North Mathilda Avenue 1764 Sunnyvale, CA 94089 1765 USA 1767 Email: pyegani@juniper.net