idnits 2.17.1 draft-ietf-mext-binding-revocation-14.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 (October 26, 2009) is 5289 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 29, 2010 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Starent Networks 9 P. Yegani 10 Juniper Networks 11 October 26, 2009 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-14.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 29, 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 . . . . . . . . . . . . . . . . . . . . . . . 37 107 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 108 15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 109 15.2. Informative References . . . . . . . . . . . . . . . . . . 38 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 [RFC5648], 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 [RFC5648], 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 [RFC5648]. 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]. According to 644 [RFC5213], the mobile access gateway is allowed to include this 645 option in the Proxy Binding Update to indicate the proxy Care-of 646 address of the mobile node mobility session. This option MAY be 647 included to indicate the proxy Care-of address of the mobile 648 node's binding that is being revoked. In the case when the Global 649 (G) bit is set, this option identifies all mobility bindings that 650 share the same proxy care-of address. 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 [RFC5648]. 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. 978 o If the home agent needs to only revoke the mobile node's IPv4 home 979 address binding, the home agent MUST set the IPv4 HoA Binding Only 980 (V) bit and MUST include the mobile node's registered IPv4 home 981 address that is being revoked in the IPv4 Home Address option. 983 When the home agent sends a Binding Revocation Indication to the 984 mobile node, the home agent sets a flag in the mobile node BCE to 985 indicate that revocation is in progress and starts the 986 InitMINDelayBRIs timer. The home agent maintains the mobile node BCE 987 in this state until it receives a Binding Revocation Acknowledgement 988 or retransmits the Binding Revocation Indication message as described 989 in Section 6.3. 991 In a race condition case, the home agent may receive a Binding Update 992 from the mobile node while the mobile node's BCE has the revocation 993 in progress flag set, the home agent SHOULD handle this case based on 994 the reason for sending the Binding Revocation Indication message and 995 its local policy. In this case, if the home agent accepts the 996 Binding Update, it needs to update the mobile node BCE accordingly, 997 e.g. removing the revocation in progress flag. 999 When the home agent needs to revoke one or more of a mobile node 1000 bindings that were created using Multiple Care-of address 1001 registration as in [RFC5648], the home agent MUST include all the 1002 related BID mobility options that identify these bindings in the 1003 Binding Revocation Indication message. In the case when the home 1004 agent needs to revoke all of the mobile node bindings, the home agent 1005 SHOULD NOT include any of the BID mobility options. 1007 When the home agent receives a packet carrying a valid Binding 1008 Revocation Acknowledgement message, the home agent follows 1009 Section 6.2 in processing this message. 1011 8. Local Mobility Anchor Operation 1013 8.1. Sending Binding Revocation Indication 1015 To terminate a mobile node PMIPv6 registration and its current 1016 binding with the local mobility anchor, the local mobility anchor 1017 sends a packet to the mobile access gateway containing a Binding 1018 Revocation Indication message following the procedure in Section 6.1 1019 and the following rules: 1021 o The Proxy Mobile IP (P) bit MUST be set to indicate that the 1022 binding being revoked is a PMIPv6 binding. 1024 o The Revocation Trigger field MUST be set to indicate to the mobile 1025 access gateway the reason for removing the specified mobile node 1026 PMIPv6 binding at the local mobility anchor. The Revocation 1027 Trigger may be used by the mobile access gateway to learn the 1028 mobile node's latest movement. 1030 o The packet MUST contain the Mobile Node Identifier, MN-ID, option 1031 which contains the mobile node's NAI that was used in the Proxy 1032 Binding Update during the mobile node registration. 1034 o If the Mobile Node Identifier, MN-ID, is registered in more than 1035 one of the mobile node's BCE and the local mobility anchor does 1036 NOT need to revoke all of the mobile node's bindings, the Binding 1037 Revocation Indication message MUST contain another identifier to 1038 uniquely identify the mobile node binding(s) that is being 1039 revoked, e.g., at least one Home Network Prefix option which 1040 contains the mobile node's registered Home Network Prefix (HNP) 1041 for the binding being revoked. 1043 o In case of revoking all Per-Peer bindings, the local mobility 1044 anchor MUST set the Global (G) bit and the Revocation Trigger MUST 1045 contain the value "Per-Peer Policy" to request the mobile access 1046 gateway to remove all Per-Peer bindings that are registered with 1047 the local mobility anchor and this mobile access gateway. 1049 o The proxy Care-of address for the binding MUST be used as the 1050 destination address in the packet's IPv6. However, in the case 1051 when IPsec is used to protect the Proxy MIPv6 signaling as 1052 specified in [RFC5213], the destination address MUST be set to the 1053 mag_address that is being used for keying the IPsec SA. If the 1054 mag_address is different than the mobile node proxy Care-of 1055 address, the Alternate Care-of address option MUST be included and 1056 MUST contain the mobile node proxy Care-of address. 1058 The local mobility anchor MAY delete the mobile node(s) IP tunnel 1059 immediately after sending the initial Binding Revocation Indication 1060 and before receiving the Binding Revocation Acknowledgement message. 1062 When the local mobility anchor sends a Binding Revocation Indication 1063 to the mobile access gateway to remove a specific binding, the local 1064 mobility anchor sets a flag in the mobile node proxy BCE to indicate 1065 that revocation is in progress and starts the InitMINDelayBRIs timer. 1066 The local mobility anchor SHOULD maintain the mobile node proxy BCE 1067 in this state until it receives a Binding Revocation Acknowledgement 1068 or the BRIMaxRetransmitNumber is reached. In the case when the local 1069 mobility anchor sets the Revocation Trigger field to a value which 1070 indicates inter-MAG handover, the local mobility anchor MAY switch 1071 the mobile node IP tunnel to the target mobile access gateway before 1072 sending the Binding Revocation Indication to the source mobile access 1073 gateway. 1075 In a race condition case, the local mobility anchor may receive a 1076 Proxy Binding Update from the mobile access gateway while the mobile 1077 node's proxy BCE has the revocation in progress flag set. The local 1078 mobility anchor should handle this case based on the reason for 1079 sending the Binding Revocation Indication message and its local 1080 policy. In this case, if the local mobility anchor accepts the Proxy 1081 Binding Update, it needs to update the mobile node proxy BCE 1082 accordingly, e.g. removing the revocation in progress flag. 1084 When the local mobility anchor needs to revoke all the mobile nodes 1085 proxy BCEs that are registered with the local mobility anchor and the 1086 mobile access gateway peer, it MUST set the Global (G) bit and set 1087 the value of the Revocation Trigger field to "Per-Peer Policy". In 1088 this case, the local mobility anchor MUST NOT include any mobility 1089 options in this Binding Revocation Indication message. 1091 When the local mobility anchor needs to revoke all mobile nodes proxy 1092 BCEs that belong to a specific realm and are registered with the 1093 local mobility anchor and the mobile access gateway peer, the local 1094 mobility anchor MUST set the Global (G) bit and set the value of the 1095 Revocation Trigger field to "Revoking Mobility Node Local Policy". 1096 In this case, the local mobility anchor MUST include a mobility 1097 option in the Binding Revocation Indication that is shared among all 1098 the impacted mobile nodes BCEs, e.g., the mobile node identifier 1099 option, MN-ID option, with subtype value of 1. In this case, the NAI 1100 value in the MN-ID MUST follow the format where the content after the 1101 "@" character defines the realm which is shared amongst all of the 1102 impacted mobile nodes proxy BCEs. As an example: @example.com 1103 identifies all mobile nodes which their MN-ID value contain 1104 "example.com" as the realm, e.g., "1234abdelta@example.com", 1105 "axxxyzd@example.com", and "abcdefg.xyz123@example.com", but not 1106 "1234abdelta@foo.example.com". 1108 When the local mobility anchor needs to revoke a subgroup of the 1109 mobile nodes proxy BCEs that belong to a specific realm and are 1110 registered with the local mobility anchor and the mobile access 1111 gateway, the local mobility anchor MUST set the Global (G) bit and 1112 set the value of the Revocation Trigger field to "Revoking Mobility 1113 Node Local Policy". In this case, the local mobility anchor MUST 1114 include an additional mobility option to the mobile node identifier 1115 option, MN-ID option, with subtype value of 1. In other words, the 1116 impacted mobile node BCEs are those which have a MN-ID with a realm 1117 as specified above and, e.g., are assigned the same proxy care-of 1118 address as the one included in the Alternate Care-of address mobility 1119 option. 1121 When the mobile node is registered with multiple Home Network 1122 Prefixes for the same proxy care-of address, the local mobility 1123 anchor SHOULD include a HNP option for each registered HNP in the 1124 Binding Revocation Indication. Alternatively, it MAY include only 1125 the mobile node identifier, MN-ID, option with the mobile node NAI 1126 included to indicate to the mobile access gateway to remove all 1127 bindings of the specified mobile node NAI in the MN-ID option. 1129 According to Proxy Mobile IPv6 specification [RFC5213], if the local 1130 mobility anchor receives a Proxy Binding Update message from a new 1131 mobile access gateway for extending the binding lifetime of the only 1132 BCE of this mobile node with the Handoff Indicator value is set to 1133 "Inter-MAG Handover - Unknown", the local mobility anchor waits a 1134 period of MaxDelayBeforeNewBCEAssign to receive a de-registration 1135 message from the previous mobile access gateway before updating the 1136 mobile node's BCE with the new point of attachment. If a de- 1137 registration message is not received, the local mobility anchor 1138 considers the received Proxy Binding Update message as a request for 1139 a new BCE and if processed successfully, the local mobility anchor 1140 assigns a different HNP for the new BCE. 1142 This document updates the local mobility anchor's behavior in this 1143 case. If the local mobility anchor supports the binding revocation 1144 mechanism as described in this document, it SHOULD proactively send a 1145 Binding Revocation Indication message to the previous mobile access 1146 gateway instead of waiting for a de-registration from the previous 1147 mobile access gateway. In the Binding Revocation Indication message, 1148 the Revocation Trigger MUST be set to "Inter-MAG Handover - Unknown". 1150 If the local mobility anchor sent a Binding Revocation Indication 1151 message with the Revocation Trigger field set to "Inter-MAG Handover 1152 - Unknown" and while waiting for a Binding Revocation 1153 Acknowledgement, the following are possible conditions that the local 1154 mobility anchor MUST handle as specified below: 1156 o If the local mobility anchor receives a successful Binding 1157 Revocation Acknowledgement message or a de-registration message 1158 from the previous mobile access gateway, the local mobility anchor 1159 MUST update the mobile node BCE in a similar way as if it received 1160 a de-registration message as described in [RFC5213]. 1162 o If the local mobility anchor receives a Binding Revocation 1163 Acknowledgement message with the status field set to "Revocation 1164 Failed - MN is Attached", the local mobility anchor SHOULD update 1165 the mobile node BCE in a similar way as if it did NOT receive a 1166 de-registration before the MaxDelayBeforeNewBCEAssign timer 1167 expires by creating a new BCE as described in [RFC5213]. 1169 o If the local mobility anchor did not receive a Binding Revocation 1170 Acknowledgement message nor a de-registration Proxy Binding Update 1171 from the previous mobile access gateway after it exhausted all of 1172 the Binding Revocation Indication message retransmissions as 1173 described in Section 6.3, the local mobility anchor SHOULD update 1174 the mobile node's BCE in a similar way as if it did NOT receive a 1175 de-registration before the MaxDelayBeforeNewBCEAssign timer 1176 expires by creating a new BCE as described in [RFC5213]. Note 1177 that the local mobility anchor SHOULD use the recommended number 1178 of retransmissions for the Binding Revocation Indication message 1179 as described in Section 11 to avoid delaying the creation of a new 1180 binding cache entry for too long, if the mobile node is actually 1181 attaching to the new MAG with a different interface. 1183 When the mobile node is registered with an IPv4 proxy home address in 1184 addition to the Home Network Prefix where both of the IPv4 pHoA and 1185 HNP are bound to the same proxy CoA, the local mobility anchor MAY 1186 revoke the mobile node IPv4 proxy HoA binding to the current mobile 1187 node proxy CoA while maintaining the mobile node binding of the HNP 1188 to its current pCoA as part of the mobile node BCE. In this case, if 1189 the local mobility anchor decides to revoke the mobile node IPv4 1190 proxy HoA only, it MUST send a Binding Revocation Indication message 1191 following the procedure in Section 6.1 and the following rules: 1193 o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to 1194 indicate that only the IPv4 home address binding is being revoked. 1196 o The IPv4 Home Address option MUST be included with the mobile 1197 node's registered IPv4 home address that is being released in 1198 addition to the MN-ID option. 1200 o The mobile node Home Network Prefix option MUST NOT be included. 1202 o The Revocation Trigger field MUST be set to an appropriate value, 1203 e.g. "User Initiated Session(s) Termination". 1205 8.2. Receiving Binding Revocation Indication 1207 When the local mobility anchor receives a packet carrying a Binding 1208 Revocation Indication that was successfully processed as in 1209 Section 6.2, in addition, the local mobility anchor processes the 1210 message as follows: 1212 o If the (P) bit is set, the local mobility anchor MUST validate 1213 that all impacted binding(s) have the proxy binding flag set. 1215 o If the Global (G) bit is set and the Revocation Trigger field 1216 value is "Per-Peer Policy", the LMA MUST validate that the Proxy 1217 (P) bit is set and the MN-ID option is present with the mobile 1218 access gateway identity included. In addition, the local mobility 1219 anchor MUST verify that the identified mobile access gateway as 1220 per the value in the MN-ID option is authorized to use the global 1221 revocation with revocation trigger value "Per-Peer Policy", see 1222 Section 13. If the local mobility anchor processes the Global 1223 Binding Revocation Indication message successfully, it MUST accept 1224 the Binding Revocation Indication message using the Status code 1225 success. 1227 o If the mobile access gateway is not authorized to use the Per-Peer 1228 Global revocation feature or the received Binding Revocation 1229 Indication message has the Global (G) bit set and the Revocation 1230 Trigger field is set to "Per-Peer Policy", but the MN-ID option is 1231 not included, the local mobility anchor MUST reject the Binding 1232 Revocation Indication message using Status code (Global Revocation 1233 NOT Authorized). 1235 o If the Global (G) bit is set and the Revocation Trigger value is 1236 "Per-Peer Policy", and only the mobile node identifier, MN-ID, 1237 option is included, the local mobility anchor MUST revoke all 1238 mobile nodes bindings which proxy CoA is the one used as the 1239 source of the IPv6 packet that carried the Binding Revocation 1240 Indication. However, if Alternate Care-of Address option is 1241 included in addition to the mobile node identifier option, the 1242 local mobility anchor MUST revoke all mobile nodes bindings which 1243 proxy Care-of Address matches the Care-of address in the Alternate 1244 Care-of Address option. After the local mobility anchor 1245 successfully processes the Binding Revocation Indication message 1246 and identifies all impacted mobile nodes bindings, it MUST accept 1247 the Binding Revocation Indication message using the Status code 1248 success. 1250 o If the local mobility anchor accepted the Binding Revocation 1251 Indication message but one or more of the bindings identified in 1252 the received Binding Revocation Indication message has already 1253 been released, the local mobility anchor MUST accept the message 1254 and it MAY set the Status field to (partial success) and include 1255 the mobile node identifier, MN-ID, or the Home Network Prefix 1256 option to identify the binding(s) that failed the revocation 1257 procedure. 1259 o If the Global (G) bit is not set, the local mobility anchor uses 1260 the included mobility options to identify the impacted mobile node 1261 binding as follows: 1263 1. If only the mobile node identifier, MN-ID, option is included, 1264 the local mobility anchor MUST accept the message and revoke 1265 all bindings for this mobile node which use the specified 1266 mobile node NAI including the IPv4 Home Address binding(s) if 1267 present. 1269 2. If the mobile node identifier, MN-ID, and one Home Network 1270 Prefix option are included, the local mobility anchor MUST 1271 accept the message and only remove the specified mobile node 1272 proxy binding. 1274 3. If the mobile node identifier, MN-ID, option and more than one 1275 Home Network Prefix options are included, the local mobility 1276 anchor MUST accept the message and remove all bindings which 1277 are referenced by these Home Network Prefixes for the 1278 specified mobile node NAI. 1280 4. If the IPv4 HoA binding Only (V) bit is set and the mobile 1281 node identifier, MN-ID, option and the IPv4 Home Address 1282 option are included, the local mobility anchor MUST accept the 1283 message and remove only the IPv4 HoA address binding to the 1284 mobile node current proxy Care-of address. 1286 The Revocation Trigger field value in the received Binding Revocation 1287 Indication could be used by the local mobility anchor to log an event 1288 or update some local parameters which tracks the state of the peer 1289 mobile access gateway. 1291 After the local mobility anchor accepts or rejects a Binding 1292 Revocation Indication message, the local mobility anchor MUST follow 1293 Section 6.1 and Section 6.1.2 to send a Binding Revocation 1294 Acknowledgement message to the mobile access gateway. 1296 9. Mobile Access Gateway Operation 1298 9.1. Receiving Binding Revocation Indication 1300 When the mobile access gateway receives a packet carrying a Binding 1301 Revocation Indication that was successfully processed as in 1302 Section 6.2, in addition, the mobile access gateway processes the 1303 message as follows: 1305 o If the Global (G) bit is set and the Revocation Trigger field 1306 value is "Per-Peer policy", the mobile access gateway MUST 1307 validate that the Proxy (P) bit is set and no mobility options is 1308 included in the message. If the mobile access gateway processes 1309 the Global Binding Revocation Indication message successfully, it 1310 MUST accept the Binding Revocation Indication message using the 1311 Status code success. 1313 o If the Global (G) bit is set and the Revocation Trigger field 1314 value is "Revoking Mobility Node Local Policy", the mobile access 1315 gateway MUST validate that the Proxy (P) bit is set and at least 1316 the MN-ID option with the subtype value of 1 is included in the 1317 Binding Revocation Indication and it is formatted as described is 1318 Section 8.1. If the mobile access gateway processes this Global 1319 Binding Revocation Indication message successfully, it MUST accept 1320 the message using the Status code success. 1322 o If the Global (G) bit is set and the Revocation Trigger field 1323 value is "Revoking Mobility Node Local Policy", and no mobility 1324 options are included in the Binding Revocation Indication message 1325 or the mobile access gateway is not able to identify the impacted 1326 mobile nodes bindings based on the included mobility options, the 1327 mobile access gateway MUST treat this as an error scenario. In 1328 this case, the mobile access gateway MUST reject the Binding 1329 Revocation Indication message using Status code "Revoked Mobile 1330 Nodes Identity Required". 1332 o If the Revocation Trigger field value in the received Binding 1333 Revocation Indication message indicates inter-MAG handover, e.g., 1334 Inter-MAG Handover - Unknown, the mobile access gateway uses the 1335 mobility option(s) included in the Binding Revocation Indication 1336 message to identify the mobile node binding. The mobile access 1337 gateway SHOULD ensure that the mobile node is no longer attached 1338 to the mobile access gateway before accepting the BRI message 1339 using Status code success. However, if the mobile access gateway 1340 verified that the mobile node is still directly attached, the 1341 mobile access gateway MUST reject the BRI using Status code 1342 "Revocation failed - MN is Attached". 1344 o If the IPv4 HoA Binding Only (V) bit is set, the mobile access 1345 gateway uses the MN-ID option to identify the mobile node binding 1346 entry in the Binding Update List (BUL). The mobile access gateway 1347 MUST verify that the IPv4 address included in the IPv4 Home 1348 Address option in the received Binding Revocation Indication is 1349 the same as the IPv4 proxy HoA that is assigned to the mobile 1350 node. After the mobile access gateway successfully validates the 1351 received IPv4 home address as the mobile node IPv4 HoA, it MUST 1352 consider this as an indication to ONLY release the mobile node 1353 IPv4 proxy HoA binding to the mobile node current proxy CoA. 1354 Consequently, it MUST continue to maintain the mobile node IPv6 1355 proxy HoA or HNP binding to the current mobile node proxy CoA as 1356 part of the mobile node binding in the BUL entry and release all 1357 resources associated with the MN IPv4 proxy HoA binding to the MN 1358 pCoA. If the mobile access gateway processed the BRI 1359 successfully, the mobile access gateway MUST accept the BRI using 1360 Status code success. On the other hand, if the mobile access 1361 gateway is able to identify the mobile node binding using the 1362 MN-ID but failed to identify the received IPv4 proxy HoA, the 1363 mobile access gateway MUST reject the BRI using Status code 1364 "Binding Does NOT Exist". 1366 o If the mobile access gateway accepts the Binding Revocation 1367 Indication message but one or more of the bindings identified in 1368 the received Binding Revocation Indication message has already 1369 been released before processing the Binding Revocation Indication, 1370 the mobile access gateway MUST accept the Binding Revocation 1371 Indication message. In this case, the mobile access gateway MAY 1372 set the Status field to "partial success" and include the mobile 1373 node identifier, MN-ID, or the Home Network Prefix option to 1374 identify the binding(s) that failed to be removed as part of the 1375 revocation procedure. 1377 The Revocation Trigger field value in the received Binding Revocation 1378 Indication could be used by the mobile access gateway to define what 1379 actions the mobile access gateway could do to inform the mobile node 1380 that its IP connectivity to the current HNP has been terminated, 1381 e.g., if the Revocation Trigger field is set to "Administrative 1382 Reason", the mobile access gateway may send a RA message after 1383 setting the Home Network Prefix valid lifetime to zero. 1385 After the mobile access gateway accepts or rejects a Binding 1386 Revocation Indication message, the mobile access gateway MUST follow 1387 Section 6.1 and Section 6.1.2 to send a Binding Revocation 1388 Acknowledgement message to the local mobility anchor. 1390 9.2. Sending Binding Revocation Indication 1392 The mobile access gateway could send a Binding Revocation Indication 1393 message to indicate the termination of multiple mobile node bindings, 1394 e.g., when using the global revocation with the Global (G) bit is 1395 set. In this case when an event occurs which requires the mobile 1396 access gateway to inform the local mobility anchor peer to terminate 1397 all mobile nodes bindings which are registered at the local mobility 1398 anchor and the mobile access gateway, the mobile access gateway sends 1399 a Binding Revocation Indication message following the procedure in 1400 Section 6.1 and the followings: 1402 o The Proxy Binding (P) bit MUST be set to indicate that the 1403 binding(s) being revoked is a PMIPv6 binding. 1405 o The Global (G) bit MUST be set and the Revocation Trigger MUST 1406 contain a value of "Per-Peer Policy" in the Binding Revocation 1407 Indication to request the local mobility anchor to remove all Per- 1408 Peer bindings that are registered with the local mobility anchor 1409 and the mobile access gateway. In this case, the MN-ID option 1410 MUST be included in the Binding Revocation Indication and contain 1411 the mobile access gateway identity. In addition, the mobile 1412 access gateway MAY include the Alternate Care-of Address option. 1413 If included, the Alternate Care-of Address option MUST contain the 1414 proxy Care-of address the bindings of which are being impacted by 1415 this Binding Revocation Indication message. 1417 o The mobile access gateway address MAY be used as the source 1418 address in the packet's IPv6 header. 1420 As described in Section 6.3, the mobile access gateway SHOULD 1421 retransmit the Binding Revocation Indication to the local mobility 1422 anchor until it receives a matching Binding Revocation 1423 Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile 1424 access gateway MAY delete the mobile nodes IP tunnels immediately 1425 after sending the Binding Revocation Indication and before receiving 1426 a Binding Revocation Acknowledgement message from the LMA. 1428 In a response to a Binding Revocation Indication message, if the 1429 mobile access gateway receives a packet carrying a Binding Revocation 1430 Acknowledgement that was successfully processed as in Section 6.2 and 1431 the Status field indicates (Global Revocation NOT Authorized), the 1432 mobile access gateway is not authorized to participate in a Per-Peer 1433 Global Revocation. The mobile access gateway SHOULD NOT retry 1434 sending a Binding Revocation Indication with the Global (G) bit is 1435 set and the Revocation Trigger field value is set to "Per-Peer 1436 Policy" to the same local mobility agent. The mobile access gateway 1437 should raise an alarm or log an event to indicate this rejection. 1439 10. Mobile Node Operation 1441 Upon receiving a packet carrying a Binding Revocation Indication, the 1442 mobile node MUST validate the packet according to Section 6.2 and the 1443 following tests: 1445 o The mobile node MUST verify that the IP address in the Type 2 1446 routing header is its Home Address and that its Binding Update 1447 List contains an entry for that Home Address. If one of the tests 1448 fails, the mobile node SHOULD silently discard the received 1449 Binding Revocation Indication message. 1451 o If mobile node Binding Update List contains an entry for the IP 1452 address in the Type 2 routing header of the received Binding 1453 Revocation Indication packet, the mobile node MUST accept the BRI 1454 message using Status code success. 1456 o If the IPv4 HoA Binding Only (V) bit is set in the received BRI 1457 message, the mobile node MUST verify that there is an IPv4 Home 1458 Address option in the received Binding Revocation Indication and 1459 the IPv4 address included in the IPv4 Home Address option is the 1460 same as its IPv4 HoA that is assigned to the mobile node. If this 1461 verification is successful, the mobile node MUST consider this 1462 Binding Revocation Indication as an indication to ONLY release the 1463 mobile node IPv4 HoA binding to its current Care-of Address. 1464 Consequently, the mobile node MUST continue to maintain its IPv6 1465 HoA binding to the current CoA as part of the mobile node binding 1466 in the BUL entry and release all resources associated with the MN 1467 IPv4 HoA binding. In this case, the mobile node MUST accept the 1468 Binding Revocation Indication message using Status code success. 1469 On the other hand, if the IPv4 Home Address Option was NOT 1470 included in the received BRI with the (V) bit is set, the MN MUST 1471 reject the BRI message with Status code "IPv4 Home Address Option 1472 Required". Additionally, if the IPv4 HoA received in the IPv4 1473 Home Address Option is NOT the one assigned to the mobile node, 1474 the mobile node SHOULD reject the Binding Revocation Indication 1475 with Status code "Binding Does NOT Exist". 1477 o The mobile node MUST verify that the (P) bit in the Binding 1478 Revocation Indication is NOT set. If the (P) bit is set, the 1479 mobile node MUST reject the Binding Revocation Indication using 1480 Status code "Proxy Binding Revocation NOT Supported". 1482 o If the mobile node has registered multiple care-of addresses with 1483 its home agent, the mobile node MUST verify which binding is being 1484 revoked by examining the content of the Binding Revocation 1485 Indication message. If the mobile node received a Binding 1486 Revocation Indication with a single or more than one BID options 1487 and its home address is included in the Type 2 routing header, the 1488 mobile node MUST consider all of the care-of address(es) 1489 binding(s), identified in the BID options, with this home address 1490 as being revoked. In this case, if the BRI validation is 1491 successful, the mobile node MUST accept the Binding Revocation 1492 Indication message with Status code success. 1494 o If the mobile node has multiple Care-of Address bindings with its 1495 home agent and received a Binding Revocation Indication, without 1496 any BID option included and its home address was included in the 1497 Type 2 routing header, the mobile node MUST consider all of its 1498 registered care-of addresses bindings with this home address as 1499 being revoked. If the mobile node validates the BRI successfully, 1500 the mobile node MUST accept the Binding Revocation Indication 1501 message with Status code success. 1503 If the mobile node accepts or rejects the Binding Revocation 1504 Indication message, the mobile node MUST follow Section 6.1 and 1505 Section 6.1.2 to send a Binding Revocation Acknowledgement message to 1506 the home agent. Note that anytime the MN does not send a Binding 1507 Revocation Acknowledgement to a BRI, the initiator is likely to 1508 retransmit the BRI at least one time. This causes additional load on 1509 the initiator who sends the retransmissions, as well as on the MN 1510 that will receive and process them. 1512 The Revocation Trigger field value in the received Binding Revocation 1513 Indication could be used by the mobile node to define what action the 1514 mobile node could do to be able to register again and receive its IP 1515 mobility service, e.g., contacting its home operator. 1517 11. Protocol Configuration Variables 1519 Any mobility entity which is allowed to invoke the binding revocation 1520 procedure by sending a Binding Revocation Indication message SHOULD 1521 allow the following variables to be configured. 1523 BRI Maximum Number of Retries (BRIMaxRetriesNumber) 1525 This variable specifies the maximum Number of times a mobility 1526 entity can retransmit a Binding Revocation Indication message 1527 before receiving a Binding Revocation Acknowledgement message. 1528 The default value for this parameter is 1. 1530 Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) 1532 This variable specifies the initial delay timeout in seconds 1533 before the revoking mobility entity retransmits a BRI message. 1534 The default is 1 second but not to be configured less than 0.5 1535 seconds. 1537 Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT) 1539 This variable specifies the maximum delay timeout in seconds 1540 before the revoking mobility entity retransmits a BRI message. 1541 The default is 2 seconds. 1543 12. IANA Considerations 1545 This specification defines a new Binding Revocation Message using a 1546 new Mobility Header Type , as described in Section 5. The 1547 new Mobility Header type value needs to be assigned from the same 1548 numbering space as allocated for the other Mobility Header types 1549 registry. 1551 This document also creates a new registry "Binding Revocation Type" 1552 which indicates the type of the binding revocation message. The 1553 current binding revocation message types are described in Section 5.1 1554 and Section 5.2, and are the following: 1556 0 Reserved 1557 1 Binding Revocation Indication 1558 2 Binding Revocation Acknowledgement 1559 All other values are reserved 1561 Future values of the Binding Revocation Type can be allocated using 1562 Standards Action or IESG Approval [RFC5226]. 1564 In addition, this document also creates a second new registry for the 1565 Revocation Trigger which indicates the reason behind sending the 1566 Binding Revocation Indication message. The current Revocation 1567 Trigger values are described in Section 5.1, and are the following: 1569 Per-MN Revocation Trigger Values: 1570 0 Unspecified 1571 1 Administrative Reason 1572 2 Inter-MAG Handover - same Access Type 1573 3 Inter-MAG Handover - different Access Type 1574 4 Inter-MAG Handover - Unknown 1575 5 User Initiated Session(s) Termination 1576 6 Access Network Session(s) Termination 1577 7 Possible Out-of Sync BCE State 1579 Global Revocation Trigger Values: 1580 128 Per-Peer Policy 1581 129 Revoking Mobility Node Local Policy 1583 Reserved Revocation Trigger Values: 1584 250-255 Reserved For Testing Purposes only 1585 All other values are Reserved 1587 Future values of the Revocation Trigger can be allocated using 1588 Standards Action or IESG Approval [RFC5226]. 1590 Furthermore, this document creates a third new registry "Status Code" 1591 for the Status field in the Binding Revocation Acknowledgement 1592 message. The current values are described in Section 5.2, and are 1593 the following: 1595 0 success 1596 1 partial success 1597 128 Binding Does NOT Exist 1598 129 IPv4 Home Address Option Required 1599 130 Global Revocation NOT Authorized 1600 131 Revoked Mobile Nodes Identity Required 1601 132 Revocation Failed - MN is Attached 1602 133 Revocation Trigger NOT Supported 1603 134 Revocation Function NOT Supported 1604 135 Proxy Binding Revocation NOT Supported 1606 Future values of the Status field can be allocated using Standards 1607 Action or IESG Approval [RFC5226]. 1609 All fields labeled "Reserved" are only to be assigned through 1610 Standards Action or IESG Approval. 1612 13. Security Considerations 1614 This specification allows the mobility node which initiates the 1615 binding revocation procedure to revoke mobility session(s) that is 1616 currently registered with it. It is NOT allowed for any mobility 1617 node to revoke a mobile node mobility session that is not registered 1618 with this mobility node. 1620 The binding revocation protocol described in this specification uses 1621 the same security association between the mobile node and the home 1622 agent or the mobile access gateway and the local mobility anchor that 1623 is being used to exchange the MIPv6 or PMIPv6 Binding Update and 1624 Binding Acknowledgement signaling. If IPsec is used, the traffic 1625 selectors associated with the SPD entry protecting the Binding Update 1626 and Binding Acknowledgement MUST be extended to include Binding 1627 Revocation Message MH type . Extending the traffic 1628 selectors of the SPD entry in order to reuse the SA protecting the 1629 Binding Update and Binding Acknowledgement (instead of creating new 1630 ones) ensures that those SA will be up and running when the revoking 1631 entity needs to send a binding revocation signaling message. 1633 On the other hand, if IPsec is not used as the underlying security 1634 mechanism to protect the Mobile IPv6 and its extensions binding 1635 registration signaling, the used underlying security mechanism MUST 1636 provide protection against all identified security threats as 1637 described under Security Considerations in [RFC3775] and [RFC5213]. 1639 Since some mobility entities, e.g., local mobility anchor and mobile 1640 access gateway, are allowed to send and receive Binding Revocation 1641 Indication and Binding Revocation Acknowledgement for different 1642 cases, therefore, when IPsec is used to secure signaling between the 1643 local mobility anchor and mobile access gateway, it prevents any of 1644 them from processing a Binding Revocation Message that was not 1645 constructed by an authorized party. 1647 The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to 1648 restrict the creation and manipulation of proxy bindings to 1649 specifically authorized mobile access gateways. Therefore, the 1650 mobile access gateway which is authorized to create or manipulate the 1651 mobile node proxy BCE is also authorized to revoke such mobile node 1652 registration by sending a de-registration with lifetime of zero. 1653 However, since bulk termination using Binding Revocation Indication 1654 with the Global (G) bit set and the Revocation Trigger field set to 1655 "Per-Peer Policy" impacts all mobility sessions that are registered 1656 with the mobile access gateway and its local mobility anchor peer, 1657 the local mobility anchor MUST be locally configurable to authorize 1658 such specific functionality. Additional mechanisms, such as a policy 1659 store or Authentication, Authorization, and Accounting (AAA) may be 1660 employed, but these are outside the scope of this specification. 1662 14. Acknowledgements 1664 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1665 Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay 1666 Devarapalli, and Joel Hortelius for their review and comments of this 1667 draft and all colleagues who have supported the advancement of this 1668 draft effort. 1670 Also, we would like to thank Jari Arkko, Ben Campbell, Pasi Eronen, 1671 Ralph Droms, Alexey Melnikov, Tim Polk, Adrian Farrel and Robert 1672 Sparks for their reviews of this document as part of the IESG review 1673 process. 1675 15. References 1677 15.1. Normative References 1679 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1680 Requirement Levels", BCP 14, RFC 2119, March 1997. 1682 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1683 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1684 May 2008. 1686 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1687 in IPv6", RFC 3775, June 2004. 1689 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1690 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1691 (MIPv6)", RFC 4283, November 2005. 1693 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1694 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1696 [ID-PMIP6-IPv4] 1697 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1698 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 1699 (work in progress), September 2009. 1701 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 1702 and K. Nagami, "Multiple Care-of Addresses Registration", 1703 RFC 5648, October 2009. 1705 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1706 Routers", RFC 5555, June 2009. 1708 15.2. Informative References 1710 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1711 August 2002. 1713 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1714 Mobile IPv4", RFC 3543, August 2003. 1716 Authors' Addresses 1718 Ahmad Muhanna 1719 Nortel 1720 2221 Lakeside Blvd. 1721 Richardson, TX 75082 1722 USA 1724 Email: amuhanna@nortel.com 1726 Mohamed Khalil 1727 Nortel 1728 2221 Lakeside Blvd. 1729 Richardson, TX 75082 1730 USA 1732 Email: mkhalil@nortel.com 1734 Sri Gundavelli 1735 Cisco Systems 1736 170 West Tasman Drive 1737 San Jose, CA 95134 1738 USA 1740 Email: sgundave@cisco.com 1742 Kuntal Chowdhury 1743 Starent Networks 1744 30 International Place 1745 Tewksbury, MA 01876 1746 USA 1748 Email: kchowdhury@starentnetworks.com 1749 Parviz Yegani 1750 Juniper Networks 1751 1194 North Mathilda Avenue 1752 Sunnyvale, CA 94089 1753 USA 1755 Email: pyegani@juniper.net