idnits 2.17.1 draft-ietf-mext-binding-revocation-13.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 (September 30, 2009) is 5322 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-17 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 2 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: April 3, 2010 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Starent Networks 9 P. Yegani 10 Juniper Networks 11 September 30, 2009 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-13.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 April 3, 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 peer to terminate either one, multiple or all specified 68 binding(s). 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 74 2.1. Conventions used in this document . . . . . . . . . . . . 4 75 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5 77 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 78 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6 79 3.3. Multiple Care-of Addresses (Monami6) Use Case . . . . . . 7 80 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 81 3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation . . 9 82 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10 83 4. Binding Revocation Messages over IPv4 Transport Network . . . 11 84 5. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11 85 5.1. Binding Revocation Indication Message . . . . . . . . . . 13 86 5.2. Binding Revocation Acknowledgement Message . . . . . . . . 16 87 6. Binding Revocation Process Operation . . . . . . . . . . . . . 18 88 6.1. Sending Binding Revocation Message . . . . . . . . . . . . 18 89 6.1.1. Sending Binding Revocation Indication . . . . . . . . 19 90 6.1.2. Sending Binding Revocation Acknowledgement . . . . . . 19 91 6.2. Receiving Binding Revocation Message . . . . . . . . . . . 21 92 6.2.1. Receiving Binding Revocation Indication . . . . . . . 21 93 6.2.2. Receiving Binding Revocation Acknowledgement . . . . . 21 94 6.3. Retransmission of Binding Revocation Indication . . . . . 22 95 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 96 8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24 97 8.1. Sending Binding Revocation Indication . . . . . . . . . . 24 98 8.2. Receiving Binding Revocation Indication . . . . . . . . . 28 99 9. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 30 100 9.1. Receiving Binding Revocation Indication . . . . . . . . . 30 101 9.2. Sending Binding Revocation Indication . . . . . . . . . . 32 102 10. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 33 103 11. Protocol Configuration Variables . . . . . . . . . . . . . . . 34 104 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 105 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 106 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 107 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 108 15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 109 15.2. Informative References . . . . . . . . . . . . . . . . . . 39 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 112 1. Introduction 114 In the case of Mobile IPv6 and for administrative reason, sometimes 115 it becomes necessary to inform the mobile node that its registration 116 has been revoked and the mobile node is no longer able to receive IP 117 mobility service using its Home Address. A similar Mobile IPv4 118 registration revocation mechanism [RFC3543] has been specified by 119 IETF for providing a revocation mechanism for sessions that were 120 established using Mobile IPv4 registration [RFC3344]. 122 This document specifies a binding revocation mechanism that can be 123 used to revoke a mobile node's mobility session(s). The same 124 mechanism can be used to revoke bindings created using Mobile IPv6 125 [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 126 [RFC5213]. The proposed revocation mechanism uses a new Mobility 127 Header (MH) type for revocation signaling which is 128 applicable to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] 129 and can be used by any two IP mobility entities. As an example, this 130 mechanism allows a local mobility anchor (LMA), involved in providing 131 IP mobility services to a mobile node, to notify the mobile access 132 gateway (MAG) of the termination of that mobile node binding 133 registration. In another example, a mobile access gateway can use 134 this mechanism to notify its local mobility anchor peer with a bulk 135 termination of all or a subset of proxy mobile IPv6 (PMIPv6) bindings 136 that are registered with the local mobility anchor and currently 137 being served by the mobile access gateway. Any mobility entity is 138 allowed to revoke only the registration of those mobile node(s) 139 mobility sessions that are currently registered with it. 141 2. Conventions & Terminology 143 2.1. Conventions used in this document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 2.2. Terminology 151 All the general mobility related terminology and abbreviations are to 152 be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile 153 IPv6 [RFC5213] specifications. The following terms are used in this 154 specification. 156 Initiator 158 The mobility node that initiates the binding revocation procedure 159 by sending a Binding Revocation Indication message to its peer, 160 e.g., home agent, local mobility anchor, or mobile access gateway. 162 Responder 164 The mobility node that receives the Binding Revocation Indication 165 message and responds with a Binding Revocation Acknowledgement 166 message. e.g., mobile node, mobile access gateway, or local 167 mobility anchor. 169 3. Binding Revocation Protocol and Use Cases Overview 171 This specification specifies a generic binding revocation mechanism 172 where a mobility node can communicate to the mobile node or another 173 mobility node the identity of the the mobile node registration 174 binding that is being terminated. In the case when this mechanism is 175 used for bulk termination or multiple bindings, the identities of 176 these bindings are communicated to the mobile node or mobility node 177 using the same generic mechanism. The following subsections present 178 the protocol overview and applicable use cases. 180 3.1. Binding Revocation Protocol 182 In the case of Mobile IPv6, if the home network decides to terminate 183 the service of the mobile node, the home agent sends a Binding 184 Revocation Indication (BRI) message to the mobile node. The home 185 agent includes the home address (HoA) of the mobile node in the Type 186 2 routing header as specified in [RFC3775] to indicate the impacted 187 mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) 188 [RFC5555], the home agent may include the IPv4 Home Address option 189 with the mobile node assigned home IPv4 address. Additionally, if 190 the mobile node registered multiple care-of addresses [ID-MCoA], the 191 home agent includes the Binding Identifier (BID) option(s) in the 192 Binding Revocation Indication message to identify which binding is 193 being revoked. When the mobile node receives a Binding Revocation 194 Indication message with its HoA included in the Type 2 routing 195 header, the mobile node responds by sending a Binding Revocation 196 Acknowledgement (BRA) message. 198 Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation 199 procedure can be initiated by the local mobility anchor by sending a 200 Binding Revocation Indication message to communicate the termination 201 of a mobile node registration binding to the mobile access gateway. 202 In this case, the local mobility anchor includes the mobile node Home 203 Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option 204 [RFC4283] to indicate to the mobility access gateway the identity of 205 the PMIPv6 binding that needs to be terminated. When the mobile 206 access gateway receives the Binding Revocation Indication message, 207 the mobile access gateway responds to the local mobility anchor by 208 sending a Binding Revocation Acknowledgement message. 210 On the other hand, the mobile access gateway usually sends a de- 211 registration message by sending a Proxy Binding Update with a 212 lifetime of zero to indicate to the local mobility anchor of the 213 termination of the PMIPv6 mobile node binding registration. In this 214 case, the mobile access gateway includes the MN-HNP option, the MN-ID 215 option and all other required mobility options as per [RFC5213] in 216 order for the local mobility anchor to identify the mobile node 217 PMIPv6 binding. Additionally, in the case when the mobile access 218 gateway communicates a bulk termination of PMIPv6 mobility sessions, 219 the mobile access gateway sends a Binding Revocation Indication 220 message with the Global (G) bit is set and includes the mobile access 221 gateway identity in the MN-ID option, see Section 9.2 and 222 Section 8.2. When the local mobility anchor receives such Binding 223 Revocation Indication message, it ensures that the mobile access 224 gateway is authorized to send such bulk termination message, see 225 Section 13, and then processes the Binding Revocation Indication 226 message accordingly. If the local mobility anchor processes the 227 Binding Revocation Indication message successfully, the local 228 mobility anchor responds to the mobile access gateway by sending 229 Binding Revocation Acknowledgement message. 231 In any of the above cases, the initiator of the binding revocation 232 procedure, e.g., home agent, local mobility anchor, or mobile access 233 gateway, uses the Revocation Trigger field in the Binding Revocation 234 Indication message to indicate to the receiving node the reason for 235 initiating the revocation procedure. 237 3.2. MIPv6 and DSMIP6 Use Case 239 The binding revocation mechanism is applicable to Mobile IPv6 and 240 DSMIPv6 session(s) when the home agent needs to inform the mobile 241 node that its binding registration has been revoked, e.g. for an 242 administrative reason. This mechanism enables the user or the mobile 243 node to react to the revocation, e.g., reinstate its interrupted 244 Mobile IPv6 services. 246 In this case, the home agent sends a Binding Revocation Indication 247 message to indicate to the mobile node that its current mobile IPv6 248 (MIPv6) binding has been revoked and it is no longer able to receive 249 IP mobility service. The home agent includes the HoA in Type 2 250 routing header as used in [RFC3775] and sets the Revocation Trigger 251 field to a proper value, e.g., Administrative Reason. In the case of 252 DSMIPv6 session, the home agent may additionally include the mobile 253 node assigned IPv4 Home Address in the IPv4 Home Address option. 254 When the mobile node receives the Binding Revocation Indication 255 message, it sends a Binding Revocation Acknowledgement message to the 256 home agent. Figure 1 illustrates the message sequencing when home 257 agent revokes a mobile node binding registration. 259 MN HA 260 | | 261 | HoA in Type 2 Hdr | 262 |<<<------------... + ...-----------------| 263 | BRI [seq.#, Revocation Trigger] | 264 | | 265 | | 266 | BRA (HoA in Dest. Option)[seq.#, Status] | 267 |---------------------------------------->>>| 268 | | 269 | | 271 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 273 3.3. Multiple Care-of Addresses (Monami6) Use Case 275 In the case of multiple care-of addresses registration [ID-MCoA], the 276 home agent maintains different binding for each pair of care-of 277 address and home address. These bindings are also indexed and 278 identified during the mobile node registration using a BID mobility 279 option. The HA may revoke one or multiple bindings for the same 280 mobile node home address. 282 If the home agent revokes a single binding for a mobile node with 283 multiple care-of addresses registration, the home agent sends a 284 Binding Revocation Indication message to the mobile node with the 285 corresponding BID option included. If more than one of the mobile 286 node registered care-of addresses need to be revoked, the home agent 287 includes all the corresponding BID options in the same Binding 288 Revocation Indication message. Figure 2 illustrates the message flow 289 when the home agent revokes two registered Care-of addresses for the 290 same mobile node in a single Binding Revocation Indication message. 292 HA Binding Cache 293 ================ 294 MN-BID1 [CoA1+HoA] 295 MN HA MN-BID2 [CoA2+HoA] 296 | | MN-BID3 [CoA3+HoA] 297 | | MN-BID4 [CoA4+HoA] 298 | HoA in Type 2 Hdr | 299 |<<<<-------------- + ---------------------| 300 | BRI [seq.#, R. Trigger, BID1, BID4] | 301 | | 302 | | 303 | BRA (HoA in Dest. Option) [seq.#, Status] | 304 |---------------------------------------->>>>| 305 | | 306 | | 308 Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings 310 Additionally, the home agent may revoke all of the mobile node 311 registered bindings, by sending a BRI message without including any 312 BID options while the HoA is included in the Type 2 routing header. 313 Figure 1 illustrates the message flow when the home agent revokes all 314 registered Care-of addresses bindings for a mobile node in a single 315 Binding Revocation Indication message. 317 3.4. Proxy MIPv6 Use Case 319 Since the mobile node does not participate in the mobility mechanism 320 in the case of PMIPv6, there are many scenarios where the Binding 321 Revocation mechanism is needed to clean resources and make sure that 322 the mobility entities, i.e., mobile access gateway and local mobility 323 anchor, are always synchronized with respect to the status of the 324 existing PMIPv6 bindings. The binding revocation mechanism is 325 generic enough that can be used for all Proxy Mobile IPv6 scenarios 326 that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. 328 When the mobile access gateway receives a Binding Revocation 329 Indication message as in Section 9.1, the mobile access gateway sends 330 a Binding Revocation Acknowledgement message to the local mobility 331 anchor following the rules described in Section 6.1.2. Similarly, if 332 the local mobility anchor receives a Binding Revocation Indication 333 message, the local mobility anchor responds to the mobile access 334 gateway by sending a Binding Revocation Acknowledgement message. 336 3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation 338 The local mobility anchor may send a Binding Revocation Indication 339 message with the appropriate revocation trigger value to the mobile 340 access gateway that hosts a specific PMIPv6 binding to indicate that 341 the mobile node binding has been terminated and the mobile access 342 gateway can clean up the applicable resources. When the mobile 343 access gateway receives a Binding Revocation Indication message, the 344 mobile access gateway identifies the respected binding and it sends a 345 Binding Revocation Acknowledgement message to the local mobility 346 anchor. In this case, the mobile access gateway could send a Router 347 Advertisement message to the mobile node with the home network prefix 348 valid lifetime set to zero. 350 As an example, Figure 3, illustrates the message sequence for 351 revoking a mobile node binding at the source mobile access gateway 352 during the mobile node inter-MAG handover. During the inter-MAG 353 handover, the mobile node moves from the source MAG to the target 354 MAG. The target MAG sends a Proxy Binding Update with the new care- 355 of-address to the local mobility anchor to update the mobile node's 356 point of attachment. Since the mobile node binding at the local 357 mobility anchor points to the source MAG and upon receiving the Proxy 358 Binding Update from the target MAG, the local mobility anchor updates 359 the MN Binding Cache Entry (BCE) and send a Proxy Binding 360 Acknowledgement to the target MAG. The local mobility anchor can 361 send a Binding Revocation Indication message with the appropriate 362 revocation trigger value, e.g. inter-MAG handover - different Access 363 Types, to the source MAG in order to clean up the applicable 364 resources reserved for the specified mobile node binding. The source 365 mobile access gateway acknowledges the Binding Revocation Indication 366 message by sending a Binding Revocation Acknowledgement message to 367 indicate the success or failure of the termination of the mobile 368 node's binding. 370 The process identified above can also be used by the local mobility 371 anchor in scenarios other than the inter-MAG handover with the proper 372 revocation trigger value to indicate to the peer mobile access 373 gateway that a specific PMIPv6 binding or bindings have been revoked. 375 oldMAG newMAG LMA 376 | | | 377 | | PBU | 378 | |--------------------------->| 379 | | PBU triggers 380 | | BRI Msg to oldMAG 381 | | | 382 | | PBA | 383 | |<---------------------------| 384 | | | 385 | | | 386 | BRI [seq.#, R. Trigger, P bit, NAI] | 387 |<-----------------------------------------| 388 | | | 389 | | | 390 | | | 391 | | | 392 | BRA [seq.#, Status, P bit] | 393 |----------------------------------------->| 394 | | | 395 | | | 397 Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover 399 In addition, the local mobility anchor can send a Binding Revocation 400 Indication message to indicate that all bindings which are hosted by 401 the peer mobile access gateway and registered with the local mobility 402 anchor are being revoked by setting the Global (G) bit as described 403 in Section 8.1. 405 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 407 The mobile access gateway sends a BRI message with the Global (G) bit 408 set and the Revocation Trigger field set to "Per-Peer Policy" to 409 indicate that all mobility bindings which are registered at the local 410 mobility anchor and attached to the mobile access gateway are being 411 revoked as in Section 9.2. When the local mobility anchor receives 412 this Binding Revocation Indication message from the specified mobile 413 access gateway, the local mobility anchor first checks if the mobile 414 access gateway is authorized to use global revocations, then it 415 responds with the appropriate status code by sending a Binding 416 Revocation Acknowledgement message as in Section 6.1.2. 418 4. Binding Revocation Messages over IPv4 Transport Network 420 In some deployments, the network between the mobile access gateway 421 and the local mobility anchor may only support IPv4 transport. 422 Another case is when a mobile node which supports client mobile IPv6 423 roams to an access network where only IPv4 addressing and transport 424 is supported. In this case, the mobile node is required to register 425 an IPv4 home address with its home agent using a mobile IPv6 Binding 426 Update message. 428 If the Proxy Binding Update and Proxy Binding Acknowledgement 429 messages or the Binding Update and Binding Acknowledgement messages 430 are sent using UDP encapsulation [ID-PMIP6-IPv4] and [RFC5555] to 431 traverse NATs, then the Binding Revocation messages are sent using 432 the same UDP encapsulation. The same UDP source and destination port 433 numbers and IPv4 addresses used for exchanging the Proxy Binding 434 Update and Proxy Binding Acknowledgement or the Binding Update and 435 Binding Acknowledgement messages MUST be used when transporting 436 Binding Revocation messages over IPv4 using UDP encapsulation. For 437 example, the source UDP port number, the destination UDP port number, 438 the source IPv4 address, and the destination IPv4 address of the 439 Binding Revocation Indication message are set to the destination UDP 440 port number, the source UDP port number, destination IPv4 address, 441 and source IPv4 address of the latest received and successfully 442 processed Proxy Binding Update or Binding Update message, 443 respectively. For more details on tunneling Proxy Mobile IPv6 and 444 Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4] and 445 [RFC5555], respectively. 447 5. Binding Revocation Message 449 This section defines the Binding Revocation Message format using a MH 450 Type as illustrated in Figure 4. The value in the Binding 451 Revocation Type field defines whether the Binding Revocation message 452 is a Binding Revocation Indication or Binding Revocation 453 Acknowledgement. If the Binding Revocation type field is set to 1, 454 the Binding Revocation Message is a Binding Revocation Indication as 455 in Section 5.1. However, if the value is 2, it is a Binding 456 Revocation Acknowledgement message as in Section 5.2. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Payload Proto | Header Len | MH Type | Reserved | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Checksum | B.R. Type | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 465 | | 466 . Binding Revocation Message Data . 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 4: Binding Revocation Message 472 Payload Proto 474 8-bit selector. see [RFC3775] for more details. 476 Header Len 478 8-bit unsigned integer. representing the length of the Mobility 479 Header in units of 8 octets, excluding the first 8 octets. see 480 [RFC3775] for more details. 482 MH Type 484 which identifies the mobility message as a Binding 485 Revocation message. 487 Reserved 489 8-bit field reserved for future use. The value MUST be 490 initialized to zero by the sender, and MUST be ignored by the 491 receiver. 493 Checksum 495 16-bit unsigned integer. This field contains the checksum of the 496 Mobility Header. The checksum is calculated as described in 497 [RFC3775]. 499 Binding Revocation Type 501 8-bit unsigned integer. It defines the type of the Binding 502 Revocation Message. It can be assigned one of the following 503 values: 505 0 Reserved 506 1 Binding Revocation Indication Message 507 2 Binding Revocation Acknowledgement Message 508 All other values are reserved 510 Binding Revocation Message Data 512 The Binding Revocation Message Data follows the Binding Revocation 513 Message format that is defined in this document for the specified 514 value in the Binding Revocation Type field. In this document, it 515 is either a Binding Revocation Indication as in Section 5.1 or 516 Binding Revocation Acknowledgement as in Section 5.2. 518 5.1. Binding Revocation Indication Message 520 The Binding Revocation Indication (BRI) message is a Binding 521 Revocation Message which has a MH type and a Binding 522 Revocation Type value of 1. It is used by the initiator to inform 523 the responder of the identity of a specific binding or bindings which 524 IP mobility service are being revoked. Binding Revocation Indication 525 message is sent as described in Section 7, Section 8.1, and 526 Section 9.2. 528 When the value 1 is indicated in the B. R. type field of the Binding 529 Revocation Message, the format of the Binding Revocation Message Data 530 follows the Binding Revocation Indication message as in Figure 5 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | B.R. Type = 1 | R. Trigger | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Sequence # |P|V|G| Reserved | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 . . 541 . Mobility options . 542 | | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Figure 5: Binding Revocation Indication Message 547 Revocation Trigger 549 8-bit unsigned integer indicating the event which triggered the 550 initiator to send the BRI message. The Per-MN Revocation Trigger 551 values are less than 128. The per-MN revocation trigger is used 552 when the BRI message intends to revoke one or more bindings for 553 the same mobile node. The Global Revocation Trigger values are 554 greater than 128 and less than 250 and used in the BRI message 555 when the Global (G) bit is set for global revocation. The values 556 250-255 are reserved for testing purposes only. The following 557 Revocation Trigger values are currently defined: 559 Per-MN Revocation Trigger Values: 560 0 Unspecified 561 1 Administrative Reason 562 2 Inter-MAG Handover - same Access Type 563 3 Inter-MAG Handover - different Access Type 564 4 Inter-MAG Handover - Unknown 565 5 User Initiated Session(s) Termination 566 6 Access Network Session(s) Termination 567 7 Possible Out-of Sync BCE State 569 Global Revocation Trigger Values: 570 128 Per-Peer Policy 571 129 Revoking Mobility Node Local Policy 573 Reserved Revocation Trigger Values: 574 250-255 Reserved For Testing Purposes only 575 All other values are Reserved 577 Sequence # 579 A 16-bit unsigned integer used by the initiator to match a 580 returned Binding Revocation Acknowledgement with this Binding 581 Revocation Indication. This sequence number could be a random 582 number. At any time, implementations MUST ensure there is no 583 collision between the sequence numbers of all outstanding Binding 584 Revocation Indication Messages. 586 Proxy Binding (P) 588 The Proxy Binding (P) bit is set by the initiator to indicate that 589 the revoked binding(s) is a PMIPv6 binding. 591 IPv4 HoA Binding Only (V) 593 The IPv4 HoA Binding Only (V) bit is set by the initiator, home 594 agent or local mobility anchor, to indicate to the receiving 595 mobility entity the termination of the IPv4 Home Address binding 596 only as in Section 7, and Section 8.1. 598 Global (G) 600 The Global (G) bit is set by the initiator, LMA or MAG, to 601 indicate the termination of all Per-Peer mobility Bindings or 602 Multiple Bindings which share a common identifier(s) and served by 603 the initiator and responder as in Section 8.1 and Section 9.2. 605 Reserved 607 These fields are unused. They MUST be initialized to zero by the 608 sender and MUST be ignored by the receiver. 610 Mobility Options 612 Variable-length field of such length that the complete Mobility 613 Header is an integer multiple of 8 octets long. This field 614 contains zero or more TLV-encoded mobility options. This document 615 does not define any new mobility option. The receiver MUST ignore 616 and skip any options which it does not understand. These mobility 617 option(s) are used by the responder to identify the specific 618 binding or bindings that the initiator requesting to be revoked. 620 The following options are valid in a Binding Revocation Indication: 622 o Home Network Prefix option [RFC5213]. This option MAY be used 623 only when the (P) bit is set. This option MUST be present when 624 the BRI is used to revoke a single Proxy MIPv6 binding cache 625 entry. 627 o Mobile Node Identifier Option [RFC4283]. This option MUST be 628 present when the (P) bit is set. Additionally, if the Global (G) 629 bit is set by the mobile access gateway, this option MUST carry 630 the MAG identity. In this specification, only Mobile Node 631 Identifier option with subtype 1 is required and other subtypes 632 are currently not supported. 634 o Binding Identifier mobility option [ID-MCoA]. This option MUST be 635 present if the initiator requests to terminate one binding of a 636 multiple care-of addresses bindings for the same mobile node. The 637 initiator may include more than one of the BID mobility options. 639 o IPv4 Home Address option which contains the mobile node home IPv4 640 address [RFC5555]. This option MUST only be included when the 641 IPv4 HoA Binding only (V) bit is set. 643 o Alternate Care-of Address mobility option [RFC3775]. This option 644 MAY be included to indicate the Care-of Address of the mobile 645 node's binding that is being revoked. In the case when the Global 646 (G) bit is set, this option identifies all mobility bindings that 647 share the same care-of address. Additionally, if the Global (G) 648 bit is set, more than one Alternate Care-of Address mobility 649 options MAY be present in the Binding Revocation Indication 650 message. 652 If no mobility options are present in this message, 4 octets of 653 padding are necessary and the Header Len field of the Binding 654 Revocation Message will be set to 1. 656 5.2. Binding Revocation Acknowledgement Message 658 The Binding Revocation Acknowledgement (BRA) message is a Binding 659 Revocation Message which has a MH type and a Binding 660 Revocation Type value of 2. It is used to acknowledge the receipt of 661 a Binding Revocation Indication message described in Section 5.1. 662 This packet is sent as described in Section 6.1.2. 664 When the value 2 is indicated in the Binding Revocation type field of 665 the Binding Revocation Message, the format of the Binding Revocation 666 Message Data follows the Binding Revocation Acknowledgement message 667 as in Figure 6 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | B.R. Type = 2 | Status | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Sequence # |P|V|G| Reserved | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | | 677 . . 678 . Mobility options . 679 . . 680 | | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Figure 6: Binding Revocation Acknowledgement Message 685 Status 687 8-bit unsigned integer indicating the result of processing the 688 Binding Revocation Indication message by the responder. Values of 689 the Status field less than 128 indicate that the Binding 690 Revocation Indication was processed successfully by the responder. 691 Values greater than or equal to 128 indicate that the Binding 692 Revocation Indication was rejected by the responder. The 693 following status values are currently defined: 695 0 success 696 1 partial success 697 128 Binding Does NOT Exist 698 129 IPv4 Home Address Option Required 699 130 Global Revocation NOT Authorized 700 131 Revoked Mobile Nodes Identity Required 701 132 Revocation Failed - MN is Attached 702 133 Revocation Trigger NOT Supported 703 134 Revocation Function NOT Supported 704 135 Proxy Binding Revocation NOT Supported 706 Sequence # 708 The sequence number in the Binding Revocation Acknowledgement is 709 copied from the Sequence Number field in the Binding Revocation 710 Indication. It is used by the initiator, e.g., HA, LMA, MAG, in 711 matching this Binding Revocation Acknowledgement with the 712 outstanding Binding Revocation Indication. 714 Proxy Binding (P) 716 The Proxy Binding (P) bit is set if the (P) bit is set in the 717 corresponding Binding Revocation Indication message. 719 IPv4 HoA Binding Only (V) 721 The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in 722 the corresponding Binding Revocation Indication message. 724 Global (G) 726 The Global (G) bit is set if the (G) bit is set in the 727 corresponding Binding Revocation Indication message. 729 Reserved 731 These fields are unused. They MUST be initialized to zero by the 732 sender and MUST be ignored by the receiver. 734 Mobility Options 736 Variable-length field of such length that the complete Mobility 737 Header is an integer multiple of 8 octets long. This field 738 contains zero or more TLV-encoded mobility options. In the case 739 when the Status field is set to success, no mobility option is 740 required. The mobility option(s) is usually used to communicate 741 information of the bindings that failed the revocation procedure. 743 The following mobility options are valid in a Binding Revocation 744 Acknowledgement: 746 o Home Network Prefix option [RFC5213]. This option MAY be included 747 only when the (P) bit is set. 749 o Mobile Node Identifier Option [RFC4283]. This option MAY be 750 included when the (P) bit is set. This option SHOULD be included 751 if the Home Network Prefix option is included. 753 o Binding Identifier mobility option [ID-MCoA]. The responder MAY 754 include this option to indicate the specific BID that failed the 755 revocation procedure. 757 If no options are present in this message, 4 octets of padding are 758 necessary and the Header Len field of the Binding Revocation Message 759 will be set to 1. 761 6. Binding Revocation Process Operation 763 The following subsections describe the details of the generic binding 764 revocation process as used by the different mobility entities. 766 6.1. Sending Binding Revocation Message 768 When sending a Binding Revocation message, the initiator constructs 769 the packet as it would any other Mobility Header with the exception 770 of setting the MH Type field to . 772 The Binding Revocation Message MUST be protected using the same 773 underlying security association, e.g., IPsec, that is being used 774 between the two peers to protect the mobile node's Mobile IPv6 and 775 its extensions binding registration signaling. If IPsec is not used 776 as the underlying security mechanism to protect the binding 777 registration signaling, the used underlying security mechanism MUST 778 provide protection against all identified security threats as 779 described under Security Considerations in [RFC3775] and [RFC5213]. 781 6.1.1. Sending Binding Revocation Indication 783 The initiator MUST construct the Binding Revocation Message Data 784 following the format of the Binding Revocation Indication message as 785 described in Section 5.1 and the following: 787 o The initiator MUST set the Sequence Number field to a valid 788 sequence number for Binding Revocation. Since sending Binding 789 Revocation Indication message is not done on a regular basis, a 16 790 bit sequence number field is large enough to allow the initiator 791 to match the Binding Revocation Acknowledgement to the associated 792 Binding Revocation Indication using the sequence number field 793 only. 795 o If the initiator is revoking a binding that was created using 796 proxy MIPv6 registration, the initiator MUST set the Proxy Binding 797 (P) bit. 799 o If the initiator is sending the Binding Revocation Indication 800 message to revoke multiple mobility sessions, the initiator MUST 801 set the Global (G) bit. In this case, the initiator MUST set the 802 revocation trigger field to a valid value from the list of Global 803 Revocation Triggers. 805 o If the initiator is sending the Binding Revocation Indication 806 message with the Global (G) bit cleared, the initiator MUST set 807 the revocation trigger field to a valid value from the list of 808 per-MN Revocation Triggers. 810 o If the initiator is sending the Binding Revocation Indication 811 message to indicate the revocation of the mobile node IPv4 HoA 812 Binding Only, the initiator MUST set the (V) bit. In this case, 813 the initiator MUST include the IPv4 Home Address option in the BRI 814 to identify the IPv4 HoA that is being revoked. 816 6.1.2. Sending Binding Revocation Acknowledgement 818 The responder MUST send a Binding Revocation Acknowledgement message 819 to indicate the receipt and the status of processing of the 820 corresponding Binding Revocation Indication message as follows: 822 o Whenever the Binding Revocation Indication is discarded, e.g., as 823 described in Section 6.2, a Binding Revocation Acknowledgement 824 MUST NOT be sent. Otherwise the treatment depends on the 825 following rules. 827 o If the responder accepts the Binding Revocation Indication 828 message, the responder MUST send a successful Binding Revocation 829 Acknowledgement with an appropriate status code. 831 o If the responder rejects the Binding Revocation Indication 832 message, the responder MUST send a Binding Revocation 833 Acknowledgement with an appropriate failure status code. 835 If the Source Address field of the IPv6 header that carried the 836 Binding Revocation Indication message does not contain a unicast 837 address, the Binding Revocation Indication packet MUST be silently 838 discarded. 840 When the responder acknowledges the received Binding Revocation 841 Indication message, the responder MUST construct the Binding 842 Revocation Message Data following the format of the Binding 843 Revocation Acknowledgement message as described in Section 5.2 and 844 the following: 846 o The responder MUST set the Sequence Number field by copying the 847 value from the Sequence Number field of the received Binding 848 Revocation Indication. 850 o The responder MUST set the status field to a valid value that 851 reflects the status of the processing of the received Binding 852 Revocation Indication message. 854 o If the (P) bit is set in the received Binding Revocation 855 Indication, the responder MUST set the (P) bit in the Binding 856 Revocation Acknowledgement. 858 o If the Global (G) bit is set in the received Binding Revocation 859 Indication, the responder MUST set the Global (G) bit in the 860 Binding Revocation Acknowledgement. 862 o If the IPv4 HoA Binding Only (V) bit is set in the received 863 Binding Revocation Indication, the responder MUST set the (V) bit 864 in the Binding Revocation Acknowledgement. 866 o The destination IP address of the IPv6 packet of the Binding 867 Revocation Acknowledgement is set to the source IP address of the 868 received Binding Revocation Indication. 870 6.2. Receiving Binding Revocation Message 872 When receiving a Binding Revocation message, the responder MUST 873 verify the Mobility Header as described in section 9.2. of [RFC3775]. 874 If the packet is dropped due to failing any of the Mobility Headers 875 test check, the responder MUST follow the processing rules as in 876 Section 9.2 of [RFC3775]. If the responder does not support the 877 Binding Revocation Indication message and does not recognize the MH 878 type , it sends a Binding Error message with the Status 879 field set to 2 as described in [RFC3775]. 881 Upon receiving a packet carrying a Binding Revocation Message, BRI or 882 BRA, the receiving mobility entity MUST verify that the packet was 883 received protected by the security association that is being used to 884 protect the binding registration and Binding Revocation signaling 885 between the two peers, e.g., an IPsec SA. 887 6.2.1. Receiving Binding Revocation Indication 889 When the responder receives a packet carrying a Binding Revocation 890 Indication message that was successfully processed as in Section 6.2, 891 the responder, in addition, processes the message as follows: 893 o The responder MUST validate that the Binding Revocation Indication 894 is formatted as in Section 5.1. 896 o If the Revocation Trigger field is set to a value that the 897 responder does not support, the responder SHOULD reject the 898 Binding Revocation Indication message using status code 899 "Revocation Trigger NOT Supported". 901 o If the Revocation Trigger value is NOT allowed with the Binding 902 Revocation Indication message intent, e.g., the Global (G) bit is 903 set and the Revocation Trigger field value is a per-MN specific, 904 the responder SHOULD reject the Binding Revocation Indication 905 message using status code "Revocation Function NOT Supported". 907 o If the responder failed to identify the mobile node(s) bindings as 908 identified in the Binding Revocation Indication message, the 909 responder MUST reject the BRI using Status code "Binding Does NOT 910 Exist". 912 6.2.2. Receiving Binding Revocation Acknowledgement 914 When the initiator receives a packet carrying a Binding Revocation 915 Acknowledgement message that was successfully processed as in 916 Section 6.2, the initiator, in addition, processes the message and 917 examines the Status field as follows: 919 o The initiator MUST validate that the sequence number in the 920 Sequence Number field matches the sequence number of an 921 outstanding Binding Revocation Indication that was sent by the 922 initiator. If the sequence number does not match a sequence 923 number of any of the outstanding Binding Revocation Indication 924 messages, the initiator MUST silently discard the message but MAY 925 log the event. 927 o If the Status field indicates that the Binding Revocation 928 Indication was processed successfully, the initiator MUST delete 929 the current timer and the mobile node(s) binding(s) and all 930 associated resources. 932 o If the Status field indicates any value other than success, the 933 initiator SHOULD examine any mobility options included in the 934 Binding Revocation Acknowledgement. In this case, it is based on 935 the initiator local policy how to handle the mobile node binding. 936 The initiator MAY log the appropriate event to reflect the 937 received status. 939 6.3. Retransmission of Binding Revocation Indication 941 If the initiator does not receive a Binding Revocation 942 Acknowledgement in response to the outstanding Binding Revocation 943 Indication before the InitMINDelayBRIs timer expires, the initiator, 944 e.g. LMA, SHOULD retransmit the same BRI message up to the 945 BRIMaxRetriesNumber as defined in Section 11. 947 The retransmissions by the initiator MUST use an exponential back-off 948 process in which the timeout period is doubled upon each 949 retransmission, until either the initiator receives a response or the 950 timeout period reaches the value MAX_BRACK_TIMEOUT. The initiator 951 MAY continue to send these messages at this slower rate up to the 952 BRIMaxRetriesNumber. 954 If the initiator does not receive a Binding Revocation 955 Acknowledgement message after the BRIMaxRetriesNumber of retransmits 956 have been sent, the initiator SHOULD clean all resources associated 957 with this mobile node binding. The initiator may log the event. 959 7. Home Agent Operation 961 To terminate a mobile node registration and its current binding with 962 the home agent, the home agent sends a packet to the mobile node 963 containing a Binding Revocation Indication, with the packet 964 constructed as follows: 966 o The Revocation Trigger field MUST be set to indicate to the mobile 967 node the reason for revoking its IP mobility binding with the home 968 agent. The Revocation Trigger may be used by the mobile node to 969 take further steps if necessary. 971 o The Binding Revocation Indication MUST be sent using a Type 2 972 routing header which contains the mobile node's registered IPv6 973 home address for the binding being revoked. 975 o The care-of address for the binding MUST be used as the 976 destination address in the packet's IPv6 header, unless an 977 Alternate Care-of Address mobility option is included in the 978 Binding Revocation Indication. If an Alternate Care-of Address 979 option is included in the Binding Revocation Indication message, 980 the destination address in the packet's IPv6 header SHOULD be set 981 to the source IP address of the packet that carried the latest 982 successful Binding Update with the Alternate Care-of address 983 included. 985 o If the home agent needs to only revoke the mobile node's IPv4 home 986 address binding, the home agent MUST set the IPv4 HoA Binding Only 987 (V) bit and MUST include the mobile node's registered IPv4 home 988 address that is being revoked in the IPv4 Home Address option. 990 When the home agent sends a Binding Revocation Indication to the 991 mobile node, the home agent sets a flag in the mobile node BCE to 992 indicate that revocation is in progress and starts the 993 InitMINDelayBRIs timer. The home agent maintains the mobile node BCE 994 in this state until it receives a Binding Revocation Acknowledgement 995 or retransmits the Binding Revocation Indication message as described 996 in Section 6.3. 998 In a race condition case, the home agent may receive a Binding Update 999 from the mobile node while the mobile node's BCE has the revocation 1000 in progress flag set, the home agent SHOULD handle this case based on 1001 the reason for sending the Binding Revocation Indication message and 1002 its local policy. In this case, if the home agent accepts the 1003 Binding Update, it needs to update the mobile node BCE accordingly, 1004 e.g. removing the revocation in progress flag. 1006 When the home agent needs to revoke one or more of a mobile node 1007 bindings that were created using Multiple Care-of address 1008 registration as in [ID-MCoA], the home agent MUST include all the 1009 related BID mobility options that identify these bindings in the 1010 Binding Revocation Indication message. In the case when the home 1011 agent needs to revoke all of the mobile node bindings, the home agent 1012 SHOULD NOT include any of the BID mobility options. 1014 When the home agent receives a packet carrying a valid Binding 1015 Revocation Acknowledgement message, the home agent follows 1016 Section 6.2 in processing this message. 1018 8. Local Mobility Anchor Operation 1020 8.1. Sending Binding Revocation Indication 1022 To terminate a mobile node PMIPv6 registration and its current 1023 binding with the local mobility anchor, the local mobility anchor 1024 sends a packet to the mobile access gateway containing a Binding 1025 Revocation Indication message following the procedure in Section 6.1 1026 and the following rules: 1028 o The Proxy Mobile IP (P) bit MUST be set to indicate that the 1029 binding being revoked is a PMIPv6 binding. 1031 o The Revocation Trigger field MUST be set to indicate to the mobile 1032 access gateway the reason for removing the specified mobile node 1033 PMIPv6 binding at the local mobility anchor. The Revocation 1034 Trigger may be used by the mobile access gateway to learn the 1035 mobile node's latest movement. 1037 o The packet MUST contain the Mobile Node Identifier, MN-ID, option 1038 which contains the mobile node's NAI that was used in the Proxy 1039 Binding Update during the mobile node registration. 1041 o If the Mobile Node Identifier, MN-ID, is registered in more than 1042 one of the mobile node's BCE and the local mobility anchor does 1043 NOT need to revoke all of the mobile node's bindings, the Binding 1044 Revocation Indication message MUST contain another identifier to 1045 uniquely identify the mobile node binding(s) that is being 1046 revoked, e.g., at least one Home Network Prefix option which 1047 contains the mobile node's registered Home Network Prefix (HNP) 1048 for the binding being revoked. 1050 o In case of revoking all Per-Peer bindings, the local mobility 1051 anchor MUST set the Global (G) bit and the Revocation Trigger MUST 1052 contain the value "Per-Peer Policy" to request the mobile access 1053 gateway to remove all Per-Peer bindings that are registered with 1054 the local mobility anchor and this mobile access gateway. 1056 o The care-of address for the binding MUST be used as the 1057 destination address in the packet's IPv6 header, unless an 1058 Alternate Care-of Address mobility option is included in the 1059 Binding Revocation Indication message. If an Alternate Care-of 1060 Address option is included in the Binding Revocation Indication 1061 message, the destination address in the packet's IPv6 header 1062 SHOULD be set to the source IP address of the packet that carried 1063 the latest successful Proxy Binding Update with the Alternate 1064 Care-of address included. 1066 The local mobility anchor MAY delete the mobile node(s) IP tunnel 1067 immediately after sending the initial Binding Revocation Indication 1068 and before receiving the Binding Revocation Acknowledgement message. 1070 When the local mobility anchor sends a Binding Revocation Indication 1071 to the mobile access gateway to remove a specific binding, the local 1072 mobility anchor sets a flag in the mobile node proxy BCE to indicate 1073 that revocation is in progress and starts the InitMINDelayBRIs timer. 1074 The local mobility anchor SHOULD maintain the mobile node proxy BCE 1075 in this state until it receives a Binding Revocation Acknowledgement 1076 or the BRIMaxRetransmitNumber is reached. In the case when the local 1077 mobility anchor sets the Revocation Trigger field to a value which 1078 indicates inter-MAG handover, the local mobility anchor MAY switch 1079 the mobile node IP tunnel to the target mobile access gateway before 1080 sending the Binding Revocation Indication to the source mobile access 1081 gateway. 1083 In a race condition case, the local mobility anchor may receive a 1084 Proxy Binding Update from the mobile access gateway while the mobile 1085 node's proxy BCE has the revocation in progress flag set. The local 1086 mobility anchor should handle this case based on the reason for 1087 sending the Binding Revocation Indication message and its local 1088 policy. In this case, if the local mobility anchor accepts the Proxy 1089 Binding Update, it needs to update the mobile node proxy BCE 1090 accordingly, e.g. removing the revocation in progress flag. 1092 When the local mobility anchor needs to revoke all the mobile nodes 1093 proxy BCEs that are registered with the local mobility anchor and the 1094 mobile access gateway peer, it MUST set the Global (G) bit and set 1095 the value of the Revocation Trigger field to "Per-Peer Policy". In 1096 this case, the local mobility anchor MUST NOT include any mobility 1097 options in this Binding Revocation Indication message. 1099 When the local mobility anchor needs to revoke all mobile nodes proxy 1100 BCEs that belong to a specific realm and are registered with the 1101 local mobility anchor and the mobile access gateway peer, the local 1102 mobility anchor MUST set the Global (G) bit and set the value of the 1103 Revocation Trigger field to "Revoking Mobility Node Local Policy". 1104 In this case, the local mobility anchor MUST include a mobility 1105 option in the Binding Revocation Indication that is shared among all 1106 the impacted mobile nodes BCEs, e.g., the mobile node identifier 1107 option, MN-ID option, with subtype value of 1. In this case, the NAI 1108 value in the MN-ID MUST follow the format where the content after the 1109 "@" character defines the realm which is shared amongst all of the 1110 impacted mobile nodes proxy BCEs. As an example: @example.com 1111 identifies all mobile nodes which their MN-ID value contain 1112 "example.com" as the realm, e.g., "1234abdelta@example.com", 1113 "axxxyzd@example.com", and "abcdefg.xyz123@example.com", but not 1114 "1234abdelta@foo.example.com". 1116 When the local mobility anchor needs to revoke a subgroup of the 1117 mobile nodes proxy BCEs that belong to a specific realm and are 1118 registered with the local mobility anchor and the mobile access 1119 gateway, the local mobility anchor MUST set the Global (G) bit and 1120 set the value of the Revocation Trigger field to "Revoking Mobility 1121 Node Local Policy". In this case, the local mobility anchor MUST 1122 include an additional mobility option to the mobile node identifier 1123 option, MN-ID option, with subtype value of 1. In other words, the 1124 impacted mobile node BCEs are those which have a MN-ID with a realm 1125 as specified above and, e.g., are assigned the same proxy care-of 1126 address as the one included in the Alternate Care-of address mobility 1127 option. 1129 When the mobile node is registered with multiple Home Network 1130 Prefixes for the same proxy care-of address, the local mobility 1131 anchor SHOULD include a HNP option for each registered HNP in the 1132 Binding Revocation Indication. Alternatively, it MAY include only 1133 the mobile node identifier, MN-ID, option with the mobile node NAI 1134 included to indicate to the mobile access gateway to remove all 1135 bindings of the specified mobile node NAI in the MN-ID option. 1137 According to Proxy Mobile IPv6 specification [RFC5213], if the local 1138 mobility anchor receives a Proxy Binding Update message from a new 1139 mobile access gateway for extending the binding lifetime of the only 1140 BCE of this mobile node with the Handoff Indicator value is set to 1141 "Inter-MAG Handover - Unknown", the local mobility anchor waits a 1142 period of MaxDelayBeforeNewBCEAssign to receive a de-registration 1143 message from the previous mobile access gateway before updating the 1144 mobile node's BCE with the new point of attachment. If a de- 1145 registration message is not received, the local mobility anchor 1146 considers the received Proxy Binding Update message as a request for 1147 a new BCE and if processed successfully, the local mobility anchor 1148 assigns a different HNP for the new BCE. 1150 This document updates the local mobility anchor's behavior in this 1151 case. If the local mobility anchor supports the binding revocation 1152 mechanism as described in this document, it SHOULD proactively send a 1153 Binding Revocation Indication message to the previous mobile access 1154 gateway instead of waiting for a de-registration from the previous 1155 mobile access gateway. In the Binding Revocation Indication message, 1156 the Revocation Trigger MUST be set to "Inter-MAG Handover - Unknown". 1158 If the local mobility anchor sent a Binding Revocation Indication 1159 message with the Revocation Trigger field set to "Inter-MAG Handover 1160 - Unknown" and while waiting for a Binding Revocation 1161 Acknowledgement, the following are possible conditions that the local 1162 mobility anchor MUST handle as specified below: 1164 o If the local mobility anchor receives a successful Binding 1165 Revocation Acknowledgement message or a de-registration message 1166 from the previous mobile access gateway, the local mobility anchor 1167 MUST update the mobile node BCE in a similar way as if it received 1168 a de-registration message as described in [RFC5213]. 1170 o If the local mobility anchor receives a Binding Revocation 1171 Acknowledgement message with the status field set to "Revocation 1172 Failed - MN is Attached", the local mobility anchor SHOULD update 1173 the mobile node BCE in a similar way as if it did NOT receive a 1174 de-registration before the MaxDelayBeforeNewBCEAssign timer 1175 expires by creating a new BCE as described in [RFC5213]. 1177 o If the local mobility anchor did not receive a Binding Revocation 1178 Acknowledgement message nor a de-registration Proxy Binding Update 1179 from the previous mobile access gateway after it exhausted all of 1180 the Binding Revocation Indication message retransmissions as 1181 described in Section 6.3, the local mobility anchor SHOULD update 1182 the mobile node's BCE in a similar way as if it did NOT receive a 1183 de-registration before the MaxDelayBeforeNewBCEAssign timer 1184 expires by creating a new BCE as described in [RFC5213]. Note 1185 that the local mobility anchor SHOULD use the recommended number 1186 of retransmissions for the Binding Revocation Indication message 1187 as described in Section 11 to avoid delaying the creation of a new 1188 binding cache entry for too long, if the mobile node is actually 1189 attaching to the new MAG with a different interface. 1191 When the mobile node is registered with an IPv4 proxy home address in 1192 addition to the Home Network Prefix where both of the IPv4 pHoA and 1193 HNP are bound to the same proxy CoA, the local mobility anchor MAY 1194 revoke the mobile node IPv4 proxy HoA binding to the current mobile 1195 node proxy CoA while maintaining the mobile node binding of the HNP 1196 to its current pCoA as part of the mobile node BCE. In this case, if 1197 the local mobility anchor decides to revoke the mobile node IPv4 1198 proxy HoA only, it MUST send a Binding Revocation Indication message 1199 following the procedure in Section 6.1 and the following rules: 1201 o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to 1202 indicate that only the IPv4 home address binding is being revoked. 1204 o The IPv4 Home Address option MUST be included with the mobile 1205 node's registered IPv4 home address that is being released in 1206 addition to the MN-ID option. 1208 o The mobile node Home Network Prefix option MUST NOT be included. 1210 o The Revocation Trigger field MUST be set to an appropriate value, 1211 e.g. "User Initiated Session(s) Termination". 1213 8.2. Receiving Binding Revocation Indication 1215 When the local mobility anchor receives a packet carrying a Binding 1216 Revocation Indication that was successfully processed as in 1217 Section 6.2, in addition, the local mobility anchor processes the 1218 message as follows: 1220 o If the (P) bit is set, the local mobility anchor MUST validate 1221 that all impacted binding(s) have the proxy binding flag set. 1223 o If the Global (G) bit is set and the Revocation Trigger field 1224 value is "Per-Peer Policy", the LMA MUST validate that the Proxy 1225 (P) bit is set and the MN-ID option is present with the mobile 1226 access gateway identity included. In addition, the local mobility 1227 anchor MUST verify that the identified mobile access gateway as 1228 per the value in the MN-ID option is authorized to use the global 1229 revocation with revocation trigger value "Per-Peer Policy", see 1230 Section 13. If the local mobility anchor processes the Global 1231 Binding Revocation Indication message successfully, it MUST accept 1232 the Binding Revocation Indication message using the Status code 1233 success. 1235 o If the mobile access gateway is not authorized to use the Per-Peer 1236 Global revocation feature or the received Binding Revocation 1237 Indication message has the Global (G) bit set and the Revocation 1238 Trigger field is set to "Per-Peer Policy", but the MN-ID option is 1239 not included, the local mobility anchor MUST reject the Binding 1240 Revocation Indication message using Status code (Global Revocation 1241 NOT Authorized). 1243 o If the Global (G) bit is set and the Revocation Trigger value is 1244 "Per-Peer Policy", and only the mobile node identifier, MN-ID, 1245 option is included, the local mobility anchor MUST revoke all 1246 mobile nodes bindings which proxy CoA is the one used as the 1247 source of the IPv6 packet that carried the Binding Revocation 1248 Indication. However, if one or more Alternate Care-of Address 1249 options are included in addition to the mobile node identifier 1250 option, the local mobility anchor MUST revoke all mobile nodes 1251 bindings which proxy Care-of Address matches one of the Care-of 1252 address(es) in the Alternate Care-of Address option(s). After the 1253 local mobility anchor successfully processes the Binding 1254 Revocation Indication message and identifies all impacted mobile 1255 nodes bindings, it MUST accept the Binding Revocation Indication 1256 message using the Status code success. 1258 o If the local mobility anchor accepted the Binding Revocation 1259 Indication message but one or more of the bindings identified in 1260 the received Binding Revocation Indication message has already 1261 been released, the local mobility anchor MUST accept the message 1262 and it MAY set the Status field to (partial success) and include 1263 the mobile node identifier, MN-ID, or the Home Network Prefix 1264 option to identify the binding(s) that failed the revocation 1265 procedure. 1267 o If the Global (G) bit is not set, the local mobility anchor uses 1268 the included mobility options to identify the impacted mobile node 1269 binding as follows: 1271 1. If only the mobile node identifier, MN-ID, option is included, 1272 the local mobility anchor MUST accept the message and revoke 1273 all bindings for this mobile node which use the specified 1274 mobile node NAI including the IPv4 Home Address binding(s) if 1275 present. 1277 2. If the mobile node identifier, MN-ID, and one Home Network 1278 Prefix option are included, the local mobility anchor MUST 1279 accept the message and only remove the specified mobile node 1280 proxy binding. 1282 3. If the mobile node identifier, MN-ID, option and more than one 1283 Home Network Prefix options are included, the local mobility 1284 anchor MUST accept the message and remove all bindings which 1285 are referenced by these Home Network Prefixes for the 1286 specified mobile node NAI. 1288 4. If the IPv4 HoA binding Only (V) bit is set and the mobile 1289 node identifier, MN-ID, option and the IPv4 Home Address 1290 option are included, the local mobility anchor MUST accept the 1291 message and remove only the IPv4 HoA address binding to the 1292 mobile node current proxy Care-of address. 1294 The Revocation Trigger field value in the received Binding Revocation 1295 Indication could be used by the local mobility anchor to log an event 1296 or update some local parameters which tracks the state of the peer 1297 mobile access gateway. 1299 After the local mobility anchor accepts or rejects a Binding 1300 Revocation Indication message, the local mobility anchor MUST follow 1301 Section 6.1 and Section 6.1.2 to send a Binding Revocation 1302 Acknowledgement message to the mobile access gateway. 1304 9. Mobile Access Gateway Operation 1306 9.1. Receiving Binding Revocation Indication 1308 When the mobile access gateway receives a packet carrying a Binding 1309 Revocation Indication that was successfully processed as in 1310 Section 6.2, in addition, the mobile access gateway processes the 1311 message as follows: 1313 o If the Global (G) bit is set and the Revocation Trigger field 1314 value is "Per-Peer policy", the mobile access gateway MUST 1315 validate that the Proxy (P) bit is set and no mobility options is 1316 included in the message. If the mobile access gateway processes 1317 the Global Binding Revocation Indication message successfully, it 1318 MUST accept the Binding Revocation Indication message using the 1319 Status code success. 1321 o If the Global (G) bit is set and the Revocation Trigger field 1322 value is "Revoking Mobility Node Local Policy", the mobile access 1323 gateway MUST validate that the Proxy (P) bit is set and at least 1324 the MN-ID option with the subtype value of 1 is included in the 1325 Binding Revocation Indication and it is formatted as described is 1326 Section 8.1. If the mobile access gateway processes this Global 1327 Binding Revocation Indication message successfully, it MUST accept 1328 the message using the Status code success. 1330 o If the Global (G) bit is set and the Revocation Trigger field 1331 value is "Revoking Mobility Node Local Policy", and no mobility 1332 options are included in the Binding Revocation Indication message 1333 or the mobile access gateway is not able to identify the impacted 1334 mobile nodes bindings based on the included mobility options, the 1335 mobile access gateway MUST treat this as an error scenario. In 1336 this case, the mobile access gateway MUST reject the Binding 1337 Revocation Indication message using Status code "Revoked Mobile 1338 Nodes Identity Required". 1340 o If the Revocation Trigger field value in the received Binding 1341 Revocation Indication message indicates inter-MAG handover, e.g., 1342 Inter-MAG Handover - Unknown, the mobile access gateway uses the 1343 mobility option(s) included in the Binding Revocation Indication 1344 message to identify the mobile node binding. The mobile access 1345 gateway SHOULD ensure that the mobile node is no longer attached 1346 to the mobile access gateway before accepting the BRI message 1347 using Status code success. However, if the mobile access gateway 1348 verified that the mobile node is still directly attached, the 1349 mobile access gateway MUST reject the BRI using Status code 1350 "Revocation failed - MN is Attached". 1352 o If the IPv4 HoA Binding Only (V) bit is set, the mobile access 1353 gateway uses the MN-ID option to identify the mobile node binding 1354 entry in the Binding Update List (BUL). The mobile access gateway 1355 MUST verify that the IPv4 address included in the IPv4 Home 1356 Address option in the received Binding Revocation Indication is 1357 the same as the IPv4 proxy HoA that is assigned to the mobile 1358 node. After the mobile access gateway successfully validates the 1359 received IPv4 home address as the mobile node IPv4 HoA, it MUST 1360 consider this as an indication to ONLY release the mobile node 1361 IPv4 proxy HoA binding to the mobile node current proxy CoA. 1362 Consequently, it MUST continue to maintain the mobile node IPv6 1363 proxy HoA or HNP binding to the current mobile node proxy CoA as 1364 part of the mobile node binding in the BUL entry and release all 1365 resources associated with the MN IPv4 proxy HoA binding to the MN 1366 pCoA. If the mobile access gateway processed the BRI 1367 successfully, the mobile access gateway MUST accept the BRI using 1368 Status code success. On the other hand, if the mobile access 1369 gateway is able to identify the mobile node binding using the 1370 MN-ID but failed to identify the received IPv4 proxy HoA, the 1371 mobile access gateway MUST reject the BRI using Status code 1372 "Binding Does NOT Exist". 1374 o If the mobile access gateway accepts the Binding Revocation 1375 Indication message but one or more of the bindings identified in 1376 the received Binding Revocation Indication message has already 1377 been released before processing the Binding Revocation Indication, 1378 the mobile access gateway MUST accept the Binding Revocation 1379 Indication message. In this case, the mobile access gateway MAY 1380 set the Status field to "partial success" and include the mobile 1381 node identifier, MN-ID, or the Home Network Prefix option to 1382 identify the binding(s) that failed to be removed as part of the 1383 revocation procedure. 1385 The Revocation Trigger field value in the received Binding Revocation 1386 Indication could be used by the mobile access gateway to define what 1387 actions the mobile access gateway could do to inform the mobile node 1388 that its IP connectivity to the current HNP has been terminated, 1389 e.g., if the Revocation Trigger field is set to "Administrative 1390 Reason", the mobile access gateway may send a RA message after 1391 setting the Home Network Prefix valid lifetime to zero. 1393 After the mobile access gateway accepts or rejects a Binding 1394 Revocation Indication message, the mobile access gateway MUST follow 1395 Section 6.1 and Section 6.1.2 to send a Binding Revocation 1396 Acknowledgement message to the local mobility anchor. 1398 9.2. Sending Binding Revocation Indication 1400 The mobile access gateway could send a Binding Revocation Indication 1401 message to indicate the termination of multiple mobile node bindings, 1402 e.g., when using the global revocation with the Global (G) bit is 1403 set. In this case when an event occurs which requires the mobile 1404 access gateway to inform the local mobility anchor peer to terminate 1405 all mobile nodes bindings which are registered at the local mobility 1406 anchor and the mobile access gateway, the mobile access gateway sends 1407 a Binding Revocation Indication message following the procedure in 1408 Section 6.1 and the followings: 1410 o The Proxy Binding (P) bit MUST be set to indicate that the 1411 binding(s) being revoked is a PMIPv6 binding. 1413 o The Global (G) bit MUST be set and the Revocation Trigger MUST 1414 contain a value of "Per-Peer Policy" in the Binding Revocation 1415 Indication to request the local mobility anchor to remove all Per- 1416 Peer bindings that are registered with the local mobility anchor 1417 and the mobile access gateway. In this case, the MN-ID option 1418 MUST be included in the Binding Revocation Indication and contain 1419 the mobile access gateway identity. In addition, the mobile 1420 access gateway MAY include one or more Alternate Care-of Address 1421 option(s). The Alternate Care-of Address option(s) contain the 1422 proxy Care-of address(es) the bindings of which are being impacted 1423 by this Binding Revocation Indication message. 1425 o The mobile access gateway address MAY be used as the source 1426 address in the packet's IPv6 header. 1428 As described in Section 6.3, the mobile access gateway SHOULD 1429 retransmit the Binding Revocation Indication to the local mobility 1430 anchor until it receives a matching Binding Revocation 1431 Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile 1432 access gateway MAY delete the mobile nodes IP tunnels immediately 1433 after sending the Binding Revocation Indication and before receiving 1434 a Binding Revocation Acknowledgement message from the LMA. 1436 In a response to a Binding Revocation Indication message, if the 1437 mobile access gateway receives a packet carrying a Binding Revocation 1438 Acknowledgement that was successfully processed as in Section 6.2 and 1439 the Status field indicates (Global Revocation NOT Authorized), the 1440 mobile access gateway is not authorized to participate in a Per-Peer 1441 Global Revocation. The mobile access gateway SHOULD NOT retry 1442 sending a Binding Revocation Indication with the Global (G) bit is 1443 set and the Revocation Trigger field value is set to "Per-Peer 1444 Policy" to the same local mobility agent. The mobile access gateway 1445 should raise an alarm or log an event to indicate this rejection. 1447 10. Mobile Node Operation 1449 Upon receiving a packet carrying a Binding Revocation Indication, the 1450 mobile node MUST validate the packet according to Section 6.2 and the 1451 following tests: 1453 o The mobile node MUST verify that the IP address in the Type 2 1454 routing header is its Home Address and that its Binding Update 1455 List contains an entry for that Home Address. If one of the tests 1456 fails, the mobile node SHOULD silently discard the received 1457 Binding Revocation Indication message. 1459 o If mobile node Binding Update List contains an entry for the IP 1460 address in the Type 2 routing header of the received Binding 1461 Revocation Indication packet, the mobile node MUST accept the BRI 1462 message using Status code success. 1464 o If the IPv4 HoA Binding Only (V) bit is set in the received BRI 1465 message, the mobile node MUST verify that there is an IPv4 Home 1466 Address option in the received Binding Revocation Indication and 1467 the IPv4 address included in the IPv4 Home Address option is the 1468 same as its IPv4 HoA that is assigned to the mobile node. If this 1469 verification is successful, the mobile node MUST consider this 1470 Binding Revocation Indication as an indication to ONLY release the 1471 mobile node IPv4 HoA binding to its current Care-of Address. 1472 Consequently, the mobile node MUST continue to maintain its IPv6 1473 HoA binding to the current CoA as part of the mobile node binding 1474 in the BUL entry and release all resources associated with the MN 1475 IPv4 HoA binding. In this case, the mobile node MUST accept the 1476 Binding Revocation Indication message using Status code success. 1477 On the other hand, if the IPv4 Home Address Option was NOT 1478 included in the received BRI with the (V) bit is set, the MN MUST 1479 reject the BRI message with Status code "IPv4 Home Address Option 1480 Required". Additionally, if the IPv4 HoA received in the IPv4 1481 Home Address Option is NOT the one assigned to the mobile node, 1482 the mobile node SHOULD reject the Binding Revocation Indication 1483 with Status code "Binding Does NOT Exist". 1485 o The mobile node MUST verify that the (P) bit in the Binding 1486 Revocation Indication is NOT set. If the (P) bit is set, the 1487 mobile node MUST reject the Binding Revocation Indication using 1488 Status code "Proxy Binding Revocation NOT Supported". 1490 o If the mobile node has registered multiple care-of addresses with 1491 its home agent, the mobile node MUST verify which binding is being 1492 revoked by examining the content of the Binding Revocation 1493 Indication message. If the mobile node received a Binding 1494 Revocation Indication with a single or more than one BID options 1495 and its home address is included in the Type 2 routing header, the 1496 mobile node MUST consider all of the care-of address(es) 1497 binding(s), identified in the BID options, with this home address 1498 as being revoked. In this case, if the BRI validation is 1499 successful, the mobile node MUST accept the Binding Revocation 1500 Indication message with Status code success. 1502 o If the mobile node has multiple Care-of Address bindings with its 1503 home agent and received a Binding Revocation Indication, without 1504 any BID option included and its home address was included in the 1505 Type 2 routing header, the mobile node MUST consider all of its 1506 registered care-of addresses bindings with this home address as 1507 being revoked. If the mobile node validates the BRI successfully, 1508 the mobile node MUST accept the Binding Revocation Indication 1509 message with Status code success. 1511 If the mobile node accepts or rejects the Binding Revocation 1512 Indication message, the mobile node MUST follow Section 6.1 and 1513 Section 6.1.2 to send a Binding Revocation Acknowledgement message to 1514 the home agent. Note that anytime the MN does not send a Binding 1515 Revocation Acknowledgement to a BRI, the initiator is likely to 1516 retransmit the BRI at least one time. This causes additional load on 1517 the initiator who sends the retransmissions, as well as on the MN 1518 that will receive and process them. 1520 The Revocation Trigger field value in the received Binding Revocation 1521 Indication could be used by the mobile node to define what action the 1522 mobile node could do to be able to register again and receive its IP 1523 mobility service, e.g., contacting its home operator. 1525 11. 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 Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) 1540 This variable specifies the initial delay timeout in seconds 1541 before the revoking mobility entity retransmits a BRI message. 1542 The default is 1 second but not less than 0.5 seconds. 1544 Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT) 1546 This variable specifies the maximum delay timeout in seconds 1547 before the revoking mobility entity retransmits a BRI message. 1548 The default is 2 seconds. 1550 12. IANA Considerations 1552 This specification defines a new Binding Revocation Message using a 1553 new Mobility Header Type , as described in Section 5. The 1554 new Mobility Header type value needs to be assigned from the same 1555 numbering space as allocated for the other Mobility Header types 1556 registry. 1558 This document also creates a new registry "Binding Revocation Type" 1559 which indicates the type of the binding revocation message. The 1560 current binding revocation message types are described in Section 5.1 1561 and Section 5.2, and are the following: 1563 0 Reserved 1564 1 Binding Revocation Indication 1565 2 Binding Revocation Acknowledgement 1566 All other values are reserved 1568 Future values of the Binding Revocation Type can be allocated using 1569 Standards Action or IESG Approval [RFC5226]. 1571 In addition, this document also creates a second new registry for the 1572 Revocation Trigger which indicates the reason behind sending the 1573 Binding Revocation Indication message. The current Revocation 1574 Trigger values are described in Section 5.1, and are the following: 1576 Per-MN Revocation Trigger Values: 1578 0 Unspecified 1579 1 Administrative Reason 1580 2 Inter-MAG Handover - same Access Type 1581 3 Inter-MAG Handover - different Access Type 1582 4 Inter-MAG Handover - Unknown 1583 5 User Initiated Session(s) Termination 1584 6 Access Network Session(s) Termination 1585 7 Possible Out-of Sync BCE State 1587 Global Revocation Trigger Values: 1588 128 Per-Peer Policy 1589 129 Revoking Mobility Node Local Policy 1591 Reserved Revocation Trigger Values: 1592 250-255 Reserved For Testing Purposes only 1593 All other values are Reserved 1595 Future values of the Revocation Trigger can be allocated using 1596 Standards Action or IESG Approval [RFC5226]. 1598 Furthermore, this document creates a third new registry "Status Code" 1599 for the Status field in the Binding Revocation Acknowledgement 1600 message. The current values are described in Section 5.2, and are 1601 the following: 1603 0 success 1604 1 partial success 1605 128 Binding Does NOT Exist 1606 129 IPv4 Home Address Option Required 1607 130 Global Revocation NOT Authorized 1608 131 Revoked Mobile Nodes Identity Required 1609 132 Revocation Failed - MN is Attached 1610 133 Revocation Trigger NOT Supported 1611 134 Revocation Function NOT Supported 1612 135 Proxy Binding Revocation NOT Supported 1614 Future values of the Status field can be allocated using Standards 1615 Action or IESG Approval [RFC5226]. 1617 All fields labeled "Reserved" are only to be assigned through 1618 Standards Action or IESG Approval. 1620 13. Security Considerations 1622 This specification allows the mobility node which initiates the 1623 binding revocation procedure to revoke mobility session(s) that is 1624 currently registered with it. It is NOT allowed for any mobility 1625 node to revoke a mobile node mobility session that is not registered 1626 with this mobility node. 1628 The binding revocation protocol described in this specification uses 1629 the same security association between the mobile node and the home 1630 agent or the mobile access gateway and the local mobility anchor that 1631 is being used to exchange the MIPv6 or PMIPv6 Binding Update and 1632 Binding Acknowledgement signaling. If IPsec is used, the traffic 1633 selectors associated with the SPD entry protecting the Binding Update 1634 and Binding Acknowledgement MUST be extended to include Binding 1635 Revocation Message MH type . Extending the traffic 1636 selectors of the SPD entry in order to reuse the SA protecting the 1637 Binding Update and Binding Acknowledgement (instead of creating new 1638 ones) ensures that those SA will be up and running when the revoking 1639 entity needs to send a binding revocation signaling message. 1641 On the other hand, if IPsec is not used as the underlying security 1642 mechanism to protect the Mobile IPv6 and its extensions binding 1643 registration signaling, the used underlying security mechanism MUST 1644 provide protection against all identified security threats as 1645 described under Security Considerations in [RFC3775] and [RFC5213]. 1647 Since some mobility entities, e.g., local mobility anchor and mobile 1648 access gateway, are allowed to send and receive Binding Revocation 1649 Indication and Binding Revocation Acknowledgement for different 1650 cases, therefore, when IPsec is used to secure signaling between the 1651 local mobility anchor and mobile access gateway, it prevents any of 1652 them from processing a Binding Revocation Message that was not 1653 constructed by an authorized party. 1655 The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to 1656 restrict the creation and manipulation of proxy bindings to 1657 specifically authorized mobile access gateways. Therefore, the 1658 mobile access gateway which is authorized to create or manipulate the 1659 mobile node proxy BCE is also authorized to revoke such mobile node 1660 registration by sending a de-registration with lifetime of zero. 1661 However, since bulk termination using Binding Revocation Indication 1662 with the Global (G) bit set and the Revocation Trigger field set to 1663 "Per-Peer Policy" impacts all mobility sessions that are registered 1664 with the mobile access gateway and its local mobility anchor peer, 1665 the local mobility anchor MUST be locally configurable to authorize 1666 such specific functionality. Additional mechanisms, such as a policy 1667 store or Authentication, Authorization, and Accounting (AAA) may be 1668 employed, but these are outside the scope of this specification. 1670 14. Acknowledgements 1672 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1673 Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay 1674 Devarapalli, and Joel Hortelius for their review and comments of this 1675 draft and all colleagues who have supported the advancement of this 1676 draft effort. 1678 Also, we would like to thank Jari Arkko, Ben Campbell, Pasi Eronen, 1679 Ralph Droms, Alexey Melnikov, Tim Polk, Adrian Farrel and Robert 1680 Sparks for their reviews of this document as part of the IESG review 1681 process. 1683 15. References 1685 15.1. Normative References 1687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1688 Requirement Levels", BCP 14, RFC 2119, March 1997. 1690 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1691 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1692 May 2008. 1694 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1695 in IPv6", RFC 3775, June 2004. 1697 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1698 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1699 (MIPv6)", RFC 4283, November 2005. 1701 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1702 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1704 [ID-PMIP6-IPv4] 1705 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1706 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 1707 (work in progress), September 2009. 1709 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1710 "Multiple Care-of Addresses Registration", 1711 draft-ietf-monami6-multiplecoa-14 (work in progress), 1712 May 2009. 1714 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1715 Routers", RFC 5555, June 2009. 1717 15.2. Informative References 1719 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1720 August 2002. 1722 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1723 Mobile IPv4", RFC 3543, August 2003. 1725 Authors' Addresses 1727 Ahmad Muhanna 1728 Nortel 1729 2221 Lakeside Blvd. 1730 Richardson, TX 75082 1731 USA 1733 Email: amuhanna@nortel.com 1735 Mohamed Khalil 1736 Nortel 1737 2221 Lakeside Blvd. 1738 Richardson, TX 75082 1739 USA 1741 Email: mkhalil@nortel.com 1743 Sri Gundavelli 1744 Cisco Systems 1745 170 West Tasman Drive 1746 San Jose, CA 95134 1747 USA 1749 Email: sgundave@cisco.com 1751 Kuntal Chowdhury 1752 Starent Networks 1753 30 International Place 1754 Tewksbury, MA 01876 1755 USA 1757 Email: kchowdhury@starentnetworks.com 1758 Parviz Yegani 1759 Juniper Networks 1760 1194 North Mathilda Avenue 1761 Sunnyvale, CA 94089 1762 USA 1764 Email: pyegani@juniper.net