idnits 2.17.1 draft-ietf-mext-binding-revocation-04.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? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 24, 2009) is 5511 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) == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-07 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-11 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-09 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: September 25, 2009 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Starent Networks 9 P. Yegani 10 Juniper Networks 11 March 24, 2009 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-04.txt 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on September 25, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Abstract 53 This document defines a binding revocation mechanism to terminate a 54 mobile node's mobility session and the associated resources. These 55 semantics are generic enough and can be used by mobility entities in 56 the case of Mobile IPv6 and its extensions. This mechanism allows 57 the mobility entity which initiates the revocation procedure to 58 request its corresponding one to terminate either one, multiple or 59 all specified binding cache entries. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 65 2.1. Conventions used in this document . . . . . . . . . . . . 4 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 68 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 69 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6 70 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 71 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 72 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 73 Revocation . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 9 75 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 9 76 5. Binding Revocation Messages over IPv4 Transport Network . . . 10 77 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10 78 6.1. Binding Revocation Indication Message . . . . . . . . . . 11 79 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14 80 7. Binding Revocation Process Considerations . . . . . . . . . . 17 81 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 17 82 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 18 83 7.3. Retransmission of Binding Revocation Indication . . . . . 19 84 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19 85 8.1. Sending Binding Revocation Indication . . . . . . . . . . 19 86 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20 87 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 21 88 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 21 89 9.1.1. Sending Binding Revocation Indication . . . . . . . . 21 90 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23 91 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 24 92 9.2.1. Receiving Binding Revocation Indication . . . . . . . 24 93 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 25 94 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26 95 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26 96 10.1.1. Receiving Binding Revocation Indication . . . . . . . 26 97 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 28 98 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 29 99 10.2.1. Sending Binding Revocation Indication . . . . . . . . 29 100 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 29 101 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 30 102 11.1. Receiving Binding Revocation Indication . . . . . . . . . 30 103 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 32 104 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 32 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 106 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 108 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 109 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 110 16.2. Informative References . . . . . . . . . . . . . . . . . . 35 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 113 1. Introduction 115 In the case of Mobile IPv6 and for administrative reason, sometimes 116 it becomes necessary to inform the mobile node that its registration 117 has been revoked and the mobile node is no longer able to receive IP 118 mobility service using its Home Address. A similar Mobile IPv4 119 registration revocation mechanism [RFC3543] has been specified by 120 IETF for providing a revocation mechanism for sessions that were 121 established using Mobile IPv4 registration [RFC3344]. 123 This document specifies a binding revocation mechanism that can be 124 used to revoke a mobile node's mobility session(s). The same 125 mechanism can be used to revoke bindings created using Mobile IPv6 126 [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 127 [RFC5213]. The proposed revocation mechanism uses a new MH type 128 for revocation signaling which is applicable to Mobile 129 IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any 130 two IP mobility entities. As an example, this mechanism allows a 131 local mobility anchor, involved in providing IP mobility services to 132 a mobile node, to notify the mobile access gateway of the termination 133 of a mobile node binding registration. In another example, a mobile 134 access gateway can use this mechanism to notify its local mobility 135 anchor peer with a bulk termination of all or a subset of Proxy 136 Mobile IPv6 bindings that are registered with the local mobility 137 anchor and currently being served by the mobile access gateway. 139 2. Conventions & Terminology 141 2.1. Conventions used in this document 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 2.2. Terminology 149 All the general mobility related terminology and abbreviations are to 150 be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile 151 IPv6 [RFC5213] specifications. 153 3. Binding Revocation Protocol and Use Cases Overview 155 This specification specifies a binding revocation mechanism where a 156 mobility node can communicate to the mobile node or another mobility 157 node the termination of the mobile node registration binding. The 158 following subsections describe the protocol overview and applicable 159 use cases. 161 3.1. Binding Revocation Protocol 163 In the case of Mobile IPv6, if the home network decides to terminate 164 the service of the mobile node, the home agent sends a Binding 165 Revocation Indication (BRI) message to the mobile node. The home 166 agent includes the HoA in the Type 2 routing header as specified in 167 [RFC3775] to indicate the impacted mobile node binding. In the case 168 of DSMIPv6 [ID-DSMIP6], the home agent may include the IPv4 Home 169 Address Option with the mobile node assigned home IPv4 address. 170 Additionally, if the mobile node registered multiple care-of 171 addresses [ID-MCoA], the home agent includes the Binding ID option(s) 172 in the Binding Revocation Indication message to identify which 173 binding is being revoked. When the mobile node receives a BRI 174 message with its HoA included in the Type 2 routing header and the 175 Acknowledge (A) bit is set, the mobile node responds by sending a 176 Binding Revocation Acknowledgement (BRA) message. 178 Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation 179 procedure can be initiated by the local mobility anchor by sending a 180 BRI message to communicate the termination of a mobile node 181 registration binding to the mobility access gateway. In this case, 182 the local mobility anchor includes the mobile node Home Network 183 Prefix option [RFC5213] and the MN-ID option [RFC4283] to indicate to 184 the mobility access gateway the identity of the PMIPv6 binding that 185 needs to be terminated. When the mobility access gateway receives 186 the BRI message with the (A) bit set, the mobility access gateway 187 responds to the local mobility anchor by sending a BRA message. 189 On the other hand, the MAG usually sends a de-registration message by 190 sending a Proxy BU with a lifetime of zero to indicate to the LMA of 191 the termination of the PMIPv6 mobile node binding registration. In 192 this case, the MAG includes the MN HNP option, the MN-ID option and 193 all other required mobility options as per [RFC5213] in order for the 194 LMA to identify the mobile node PMIPv6 binding. Additionally, in the 195 case when the mobility access gateway communicates a bulk termination 196 of PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A) 197 bits set and includes the MAG identity in the MN-ID option. When the 198 LMA receives such BRI message, it ensures that the mobility access 199 gateway is authorized to send such bulk termination message and then 200 process the BRI message accordingly. If the local mobility anchor 201 processes the BRI message successfully, the LMA responds to the 202 mobile access gateway by sending the BRA message. 204 In any of the above cases, the initiator of the binding revocation 205 procedure, e.g., HA, LMA, MAG, uses the Revocation Trigger field in 206 the Binding Revocation Indication message to indicate to the 207 receiving node the reason for initiating the revocation procedure. 209 3.2. MIPv6 and DSMIP6 Use Case 211 Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 212 session(s) when the home agent needs to inform the mobile node that 213 its binding registration has been revoked, e.g. for an administrative 214 reason. This mechanism enables the home domain to dynamically allow 215 the user to act upon the revocation message in order to recover its 216 interrupted mobile IPv6 services. 218 In this case, the home agent sends a BRI message to indicate to the 219 mobile node that its current mobile IPv6 binding has been revoked and 220 it no longer can receive IP mobility service. The home agent 221 includes the mobile node home address in Type 2 routing header as 222 used in [RFC3775] and sets the Revocation Trigger field to a proper 223 value, e.g. Administrative Reason. In the case of DSMIPv6 session, 224 the home agent may additionally include the mobile node assigned IPv4 225 Home Address in the IPv4 Home Address Option. When the mobile node 226 receives the BRI message, it sends a BRA message as described in 227 Section 11.2 to the home agent. Figure 1 illustrates the message 228 sequencing when home agent revokes a mobile node binding 229 registration. 231 MN HA 232 | | 233 | HoA in Type 2 Hdr | 234 |<<<------------... + ...-----------------| 235 | BRI [seq.#, A bit, Revocation Trigger] | 236 | | 237 | | 238 | BRA (HoA in Dest. Option)[seq.#, Status] | 239 |---------------------------------------->>>| 240 | | 241 | | 243 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 245 3.3. Multi-Care of Addresses (Monami6) Use Case 247 In the case of multiple care-of addresses registration [ID-MCoA], the 248 home agent maintains different binding for each pair of care-of 249 address and home address. These bindings are also indexed and 250 identified during the mobile node registration using a Binding ID 251 mobility option. The HA may revoke one or multiple bindings for the 252 same mobile node home address. 254 If the home agent revokes a single binding for a mobile node with 255 multiple care-of addresses registration, the home agent sends a BRI 256 message to the mobile node with the corresponding BID option 257 included. If more than one of the mobile node registered care-of 258 addresses need to be revoked, the home agent includes all the 259 corresponding Binding ID options in the same BRI message. Figure 2 260 illustrates the message flow when the HA revokes two registered 261 Care-of addresses for the same MN in a single BRI message. 263 HA Binding Cache 264 ================ 265 MN-BID1 [CoA1+HoA] 266 MN HA MN-BID2 [CoA2+HoA] 267 | | MN-BID3 [CoA3+HoA] 268 | | MN-BID4 [CoA4+HoA] 269 | HoA in Type 2 Hdr | 270 |<----------------- + --------------------| 271 | BRI [seq.#, A bit, BID1, BID4] | 272 | | 273 | | 274 | BRA (HoA in Dest. Option) [seq.#, Status] | 275 |------------------------------------------>| 276 | | 277 | | 279 Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings 281 Additionally, the home agent may revoke all of the mobile node 282 registered bindings, by sending a BRI message without including any 283 BID options while the HoA is included in the Type 2 routing header. 284 Figure 1 illustrates the message flow when the home agent revokes all 285 registered Care-of addresses bindings for a MN in a single BRI 286 message. 288 3.4. Proxy MIPv6 Use Case 290 Since the Mobile node does not participate in the mobility mechanism 291 in the case of PMIPv6, there are many scenarios where Binding 292 Revocation mechanism is needed to clean resources and make sure that 293 the mobility entities, e.g. MAG and LMA, are always synchronized 294 with respect to the status of the existing proxy mobile IPv6 295 bindings. The binding revocation mechanism is generic enough that 296 can be used for all Proxy Mobile IPv6 scenarios that follow [RFC5213] 297 and [ID-PMIP6-IPv4] specifications. 299 When the MAG receives a BRI message as in Section 10.1.1, the MAG 300 sends a BRA message to the LMA following the rules described in 301 Section 10.1.2. Similarly, if the LMA receives a BRI message with 302 the (A) bit is set, the LMA responds to the MAG by sending a BRA 303 message. 305 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation 307 The local mobility anchor may send a BRI message to the mobile access 308 gateway, hosting a specific proxy mobile IPv6 binding, with the 309 appropriate value in the revocation trigger field to indicate that 310 the mobile node binding has been terminated and the MAG can clean up 311 the applicable resources. When the MAG receives a BRI message, the 312 MAG identifies the respected binding and if the (A) bit was set in 313 the received BRI message, the MAG sends a BRA message to the LMA. In 314 this case, the MAG could send a Router Advertisement message to the 315 MN with the home network prefix lifetime set to zero. 317 As an example, Figure 3, illustrates the message sequence for 318 revoking a mobile node binding at the source MAG during the MN inter- 319 MAG handoff. During the inter-MAG handoff, the mobile node moves 320 from the source MAG to the target MAG. The target MAG sends a PBU 321 with the new care-of-address to the LMA to update the mobile node 322 point of attachment. Since the MN binding at the LMA points to the 323 source MAG and upon receiving the PBU from the target MAG, LMA 324 updates the MN BCE and send a PBA to the target MAG. LMA can send a 325 BRI message with the appropriate revocation trigger value, e.g. 326 inter-MAG handoff - same Access Types, to the source MAG in order to 327 clean up the applicable resources reserved for the specified MN 328 binding. The MAG acknowledges the BRI message by sending a BRA 329 message to indicate the success or failure of the termination of the 330 mobile node binding. 332 The process identified above can also be used by the LMA in scenarios 333 other than the inter-MAG handoff with the proper revocation trigger 334 value to indicate to the peer MAG that a specific proxy mobile IPv6 335 binding or bindings have been revoked. 337 oldMAG newMAG LMA 338 | | | 339 | | PBU | 340 | |--------------------------->| 341 | | PBU triggers 342 | | BRI Msg to oldMAG 343 | | | 344 | | PBA | 345 | |<---------------------------| 346 | | | 347 | | | 348 | BRI [seq.#, R. Trigger, P, A bits, NAI] | 349 |<-----------------------------------------| 350 | | | 351 | | | 352 | | | 353 | | | 354 | BRA [seq.#, Status, P bit] | 355 |----------------------------------------->| 356 | | | 357 | | | 359 Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff 361 In addition, the LMA can send a BRI message to indicate that all 362 bindings which are hosted by the peer MAG and registered with the LMA 363 are being revoked by setting the (G) bit as described in 364 Section 9.1.1. 366 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 368 The mobile access gateway sends a BRI message with the (G) bit is set 369 to indicate that all mobility bindings which are registered at the 370 LMA and attached to the MAG are being revoked as in Section 10.2.1. 371 When the LMA receives a BRI message with the (G) bit is set from a 372 specified MAG, the LMA checks if the MAG is authorized to use global 373 revocations and responds with the appropriate status code by sending 374 a BRA message as in Section 9.2.2. 376 4. Security Model 378 The binding revocation protocol described here uses the same security 379 association between the MN and the HA or the MAG and the LMA that has 380 been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and 381 BA when the mobile node binding was created. If IPsec is used, the 382 traffic selectors associated with the SPD entry protecting BU and BA 383 MUST be extended to include Binding Revocation Signaling MH type 384 . Extending the traffic selectors of the SPD entry in 385 order to reuse the SA protecting BU and BA (instead of creating new 386 ones) ensures that those SA will be up and running when the revoking 387 entity needs to send a binding revocation signaling message. 389 Additionally, in the case when the LMA receives a BRI which indicates 390 a bulk termination where the (G) bit is set and the Revocation 391 Trigger field is set to "Per-Peer Policy", the LMA MUST verify that 392 the MAG sending the binding revocation indication message is 393 authorized to invoke Global revocation. 395 5. Binding Revocation Messages over IPv4 Transport Network 397 In some deployments, the network between the MAG and the LMA may only 398 support IPv4 transport. In this case, the Binding Revocation 399 messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding 400 Update and Proxy Binding Acknowledgment messages are sent using UDP 401 encapsulation to traverse NATs, then the Binding Revocation messages 402 are sent using the same UDP encapsulation. The same UDP port that 403 was used for exchanging the Proxy Binding Update and Proxy Binding 404 Acknowledgement messages will also be used when transporting Binding 405 Revocation messages over IPv4 using UDP encapsulation. In other 406 words, the destination UDP port of the BRI message MUST be set to the 407 source UDP port of the latest successfully processed Proxy Binding 408 Update message which is already saved in the mobile node BCE. For 409 more details on tunneling Proxy Mobile IPv6 signaling messages over 410 IPv4, see [ID-PMIP6-IPv4]. 412 6. Binding Revocation Message 414 This section defines the Binding Revocation Message format using a MH 415 Type as illustrated in Figure 4. The value in the Binding 416 Revocation Type field defines whether the Binding Revocation message 417 is a BRI or BRA. If the Binding Revocation type field is set to 1, 418 the Binding Revocation Message is a Binding Revocation Indication as 419 in Section 6.1. However, if the value is 2, it is a Binding 420 Revocation Acknowledgement message as in Section 6.2. 422 0 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Payload Proto | Header Len | MH Type | Reserved | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Checksum | B.R. Type | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 429 | | 430 . Binding Revocation Message Data . 431 | | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 Figure 4: Binding Revocation Message 436 Binding Revocation Type 438 8-bit unsigned integer. It defines the type of Binding Revocation 439 Message. It can be assigned one of the following values: 441 0 Reserved 442 1 Binding Revocation Indication Message 443 2 Binding Revocation Acknowledgement Message 444 All other values are reserved 446 Binding Revocation Message Data 448 The Binding Revocation Message Data follows the Binding Revocation 449 Message format that is defined in this document for the specified 450 value in the Binding Revocation Type field. It is either a BRI as 451 in Section 6.1 or BRA as in Section 6.2. 453 6.1. Binding Revocation Indication Message 455 The Binding Revocation Indication (BRI) message is a Binding 456 Revocation Message which has a MH type and a Binding 457 Revocation Type value of 1. It is used by the revoking mobility node 458 to inform the receiving mobility entity that the IP mobility service 459 of a specific binding or bindings have been revoked. Binding 460 Revocation Indication message is sent as described in Section 8.1, 461 Section 9.1.1, and Section 10.2.1. 463 When the value 1 is indicated in the B. R. type field of the Binding 464 Revocation Message, the format of the Binding Revocation Message Data 465 follows the Binding Revocation Indication message as in Figure 5 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | B.R. Type = 1 | R. Trigger | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Sequence # |A|P|V|G| Reserved | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | 474 . . 475 . Mobility options . 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Figure 5: Binding Revocation Indication Message 481 Revocation Trigger 483 8-bit unsigned integer indicating the event which triggered the 484 revoking node to send the BRI message. The Reserved and Per-MN 485 Revocation Triggers value are less than 128. The per-MN 486 revocation triggers is used when the BRI message intends to revoke 487 one or more bindings for the same mobile node. The Global 488 Revocation Trigger values are greater than 128 and used in the BRI 489 message with the (G) bit is set for for global revocation. The 490 following Revocation Trigger values are currently defined: 492 Reserved and Per-MN Revocation Trigger: 493 0 Reserved 494 1 Unspecified 495 2 Administrative Reason 496 3 Inter-MAG Handoff - same Access Types 497 4 Inter-MAG Handoff - different Access Types 498 5 Inter-MAG - Unknown Handoff 499 6 User Initiated Session(s) Termination 500 7 Access Network Session(s) Termination 501 8 IPv4 HoA Lease Expires 502 9 Possible Out-of Sync BCE State 503 250-255 Reserved For Testing Purposes only 504 All other values are Reserved 506 Global Revocation Trigger: 508 128 Per-Peer Policy 509 129 Revoking Mobility Node Local Policy 511 Sequence # 513 A 16-bit unsigned integer used by the sending mobility node to 514 match a returned Binding Revocation Acknowledgement with this 515 Binding Revocation Indication. It could be a random number. 517 Acknowledge (A) 519 The Acknowledge (A) bit is set by the sending mobility node, e.g. 520 LMA, HA, or MAG, to request a Binding Revocation Acknowledgement 521 be returned upon receipt of the Binding Revocation Indication as 522 in Section 8.1, Section 9.1.1, and Section 10.2.1. 524 Proxy Binding (P) 526 The Proxy Binding (P) bit is set by the sending mobility node to 527 indicate that the revoked binding(s) is a proxy MIPv6 binding. 529 IPv4 HoA Binding Only (V) 531 The IPv4 HoA Binding Only (V) bit is set by the sending mobility 532 node, HA or LMA, to request the receiving mobility entity the 533 termination of the IPv4 Home Address binding only as in 534 Section 8.1, and Section 9.1.1. 536 Global (G) 538 The Global (G) bit is set by the sending mobility node, LMA or 539 MAG, to request the termination of all Per-Peer mobility Bindings 540 or Multiple Bindings which share a common identifier that are 541 served by the sending and receiving mobility entities as in 542 Section 9.1.1 and Section 10.2.1. 544 Reserved 546 These fields are unused. They MUST be initialized to zero by the 547 sender and MUST be ignored by the receiver. 549 Mobility Options 551 Variable-length field of such length that the complete Mobility 552 Header is an integer multiple of 8 octets long. This field 553 contains zero or more TLV-encoded mobility options. This document 554 does not define any new mobility option. The receiver MUST ignore 555 and skip any options which it does not understand. These mobility 556 option(s) are used by the receiving mobility entity to identify 557 the specific binding or bindings that the sending mobility entity 558 requesting to be revoked. 560 The following options are valid in a Binding Revocation Indication: 562 o Home Network Prefix option [RFC5213]. This option MAY be used 563 when the (P) bit is set. This option MUST be present when the BRI 564 is used to revoke a single PMIP binding cache entry. 566 o Mobile Node Identifier Option [RFC4283]. This option is mandatory 567 when the (P) bit is set. Additionally, if the (G) bit is set by 568 the mobile access gateway, this option carries the MAG identity. 570 o Binding ID mobility option [ID-MCoA]. This option is mandatory if 571 the sending mobility entity request to terminate one binding of a 572 multi care-of addresses bindings for the same mobile node. The 573 sending mobility entity may include more than one of the Binding 574 ID mobility options. 576 o IPv4 Home Address option which contains the mobile node home IPv4 577 address [ID-DSMIP6]. This option is included only when the IPv4 578 HoA Binding only (V) bit is set. 580 o Alternate Care-of Address mobility option [RFC3775]. This option 581 MAY be included to indicate the Care-of Address of the mobile 582 node's binding that is being revoked. In the case when the Global 583 (G) bit set, this option identifies all the mobility bindings that 584 share the same care-of address. Additionally, if the Global (G) 585 bit set, more than one Alternate Care-of Address mobility options 586 MAY be present in the BRI message. 588 If no options are present in this message, 4 octets of padding are 589 necessary and the Header Len field of the Binding Revocation Message 590 will be set to 1. 592 6.2. Binding Revocation Acknowledgement Message 594 The Binding Revocation Acknowledgement (BRA) message is a Binding 595 Revocation Message which has a MH type and a Binding 596 Revocation Type value of 2. It is used to acknowledge the receipt of 597 a Binding Revocation Indication message described in Section 6.1. 598 This packet is sent as described in Section 9.2.2, Section 10.1.2, 599 and Section 11.2. 601 When the value 2 is indicated in the Binding Revocation type field of 602 the Binding Revocation Message, the format of the Binding Revocation 603 Message Data follows the Binding Revocation Acknowledgement message 604 as in Figure 6 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | B.R. Type = 2 | Status | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Sequence # |P|V|G| Reserved | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 . . 615 . Mobility options . 616 . . 617 | | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 6: Binding Revocation Acknowledgement Message 622 Status 624 8-bit unsigned integer indicating the result of processing the 625 Binding Revocation Indication message by the receiving mobility 626 entity. Values of the Status field less than 128 indicate that 627 the Binding Revocation Indication was processed successfully by 628 the receiving node. Values greater than or equal to 128 indicate 629 that the Binding Revocation Indication was rejected by the 630 receiving node. The following status values are currently 631 defined: 633 0 success 634 1 partial success 635 128 Binding Does NOT Exist 636 129 IPv4 HoA Binding Does NOT Exist 637 130 IPv4 Home Address Option Required 638 131 Global Revocation NOT Authorized 639 132 CAN NOT Identify Binding 640 133 Revocation Failed - MN is Attached 641 134 Revocation Trigger NOT Supported 642 135 Revocation Function NOT Supported 644 Sequence # 646 The sequence number in the Binding Revocation Acknowledgement is 647 copied from the Sequence Number field in the Binding Revocation 648 Indication. It is used by the revoking mobility entity, e.g. HA, 649 LMA, MAG, in matching this Binding Revocation Acknowledgement with 650 the outstanding BRI. 652 Proxy Binding (P) 654 The Proxy Binding (P) bit is set if the (P) bit is set in the 655 corresponding Binding Revocation Indication message. 657 IPv4 HoA Binding Only (V) 659 The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in 660 the corresponding BRI message. 662 Global (G) 664 The Global (G) bit is set if the (G) bit is set in the 665 corresponding BRI message. 667 Reserved 669 These fields are unused. They MUST be initialized to zero by the 670 sender and MUST be ignored by the receiver. 672 Mobility Options 674 Variable-length field of such length that the complete Mobility 675 Header is an integer multiple of 8 octets long. This field 676 contains zero or more TLV-encoded mobility options. In the case 677 when the Status field is set to success, no mobility option is 678 required. The mobility option(s) is usually used to communicate 679 information of the bindings that failed the revocation procedure. 681 The following mobility options are valid in a Binding Revocation 682 Acknowledgement: 684 o Home Network Prefix option [RFC5213]. This option MAY be included 685 when the (P) bit is set. 687 o Mobile Node Identifier Option [RFC4283]. This option MAY be 688 included when the (P) bit is set. This option SHOULD be included 689 if the Home Network Prefix option is included. 691 o Binding ID mobility option [ID-MCoA]. This option MAY be included 692 to indicate the specific Binding ID that the receiving node failed 693 to revoke. 695 If no options are present in this message, 4 octets of padding are 696 necessary and the Header Len field of the Binding Revocation Message 697 will be set to 1. 699 7. Binding Revocation Process Considerations 701 The following subsections describe the details of the binding 702 revocation generic process by the different mobility entities. 704 7.1. Sending Binding Revocation Messages 706 When sending a Binding Revocation message, the sending mobility node, 707 initiator, constructs the packet as it would any other Mobility 708 Header with the exception of setting the MH Type field to . 710 The mobility entity which initiates the revocation process MUST use 711 the underlying security association, e.g., IPsec SA, that has been 712 used to secure the mobile node binding registration signaling in 713 securing the BRI and BRA messages transmission with the responding 714 mobility entity. 716 When a mobility entity initiate the binding revocation process by 717 sending a Binding Revocation Indication message, the initiator MUST 718 construct the BRI message as described in Section 6.1. In the BRI 719 message, the initiator MUST set the Sequence Number field to the next 720 sequence number available for Binding Revocation. Since sending BRI 721 messages is not done on a regular basis, a 16 bit sequence number 722 field is large enough to allow the initiator to match the BRA to the 723 outstanding BRI with (A) bit set using the sequence number field 724 only. 726 However, when the responder acknowledges the BRI message by sending a 727 BRA, the responder MUST construct the Binding Revocation 728 Acknowledgement as described in Section 6.2. In this case, the 729 responder MUST set the Sequence Number field by copying the value 730 from the Sequence Number field of the received Binding Revocation 731 Indication. Additionally, it MUST set the status field to a valid 732 value that reflects the processing of the received Binding Revocation 733 Indication. 735 7.2. Receiving Binding Revocation Messages 737 When receiving a Binding Revocation message, the receiving mobility 738 node MUST verify the Mobility Header as described in section 9.2. of 739 [RFC3775]. If the packet is dropped due to failing any of the 740 Mobility Headers test check, the receiving node MUST follow the 741 processing rules as in Section 9.2 of [RFC3775]. If the receiving 742 node does not support the Binding Revocation Indication message and 743 does not recognize the new MH type, it sends a Binding Error message 744 with the Status field set to 2 as described in [RFC3775]. 746 Since some mobility entities, e.g., LMA and MAG, are allowed to 747 receive and possibly send a BRI or BRA for different cases, 748 therefore, if IPsec is used to secure signaling between the MAG and 749 the LMA, it prevents any possible man in the middle reflection 750 attack. 752 Upon receiving a packet carrying a Binding Revocation Indication, the 753 receiving mobility entity, responder, validates that the packet was 754 received protected with the security association that already has 755 been established with the mobility entity, initiator, and used during 756 the registration signaling phase, e.g., IPsec SA. 758 Upon receiving a packet carrying a Binding Revocation 759 Acknowledgement, the receiving mobility entity, initiator, MUST 760 validate that Sequence Number field matches the Sequence Number of an 761 outstanding Binding Revocation Indication that was sent by the 762 initiator. If the Sequence Number does not match any sequence number 763 of any of the outstanding BRI, the receiving node MUST silently 764 discard the message but MAY log the event. 766 If a mobility node receives a Binding Revocation Indication message 767 with the Revocation Trigger field is set to a value that NOT 768 supported, the receiving mobility node SHOULD reject the BRI message 769 by sending a BRA message with the status field set to "Revocation 770 Trigger NOT Supported". 772 If a mobility node receives a Binding Revocation Indication message 773 with a Revocation Trigger value that is NOT in line with the BRI 774 message intent, e.g., the Global Revocation (G) bit set and the 775 Revocation Trigger field vale is a per-MN specific, the receiving 776 mobility node SHOULD reject the BRI message by sending a BRA message 777 with the status field set to "Revocation Function NOT Supported". 779 7.3. Retransmission of Binding Revocation Indication 781 If the sending mobility entity does not receive a Binding Revocation 782 Acknowledgement in response to the outstanding Binding Revocation 783 Indication before the MINDelayBRIs timer expires, the mobility 784 entity, e.g. LMA, may retransmit the same BRI message up to the 785 BRIMaxRetriesNumber as defined in Section 12. If the revoking 786 mobility entity does not receive a BRA message after the maximum 787 number of retransmits have been sent, the revoking mobility entity 788 can clean the mobile node binding cache and all resources associated 789 with this binding. The revoking mobility entity may log the event. 791 8. Home Agent Operation 793 8.1. Sending Binding Revocation Indication 795 To terminate a mobile node registration and its current binding with 796 the home agent, the home agent sends a packet to the mobile node 797 containing a Binding Revocation Indication, with the packet 798 constructed as follows: 800 o The Acknowledge (A) bit MAY be set in the BRI to request the 801 mobile node to send a Binding Revocation Acknowledgement upon 802 receipt of the BRI. 804 o The Revocation Trigger field MUST be set in the Binding Revocation 805 Indication to indicate to the mobile node the reason for revoking 806 its IP mobility binding with the home agent. The Revocation 807 Trigger may be used by the mobile node to take further steps if 808 necessary. 810 o The Binding Revocation Indication MUST be sent using a Type 2 811 routing header which contains the mobile node's registered IPv6 812 home address for the binding being revoked. 814 o The care-of address for the binding MUST be used as the 815 destination address in the packet's IPv6 header, unless an 816 Alternate Care-of Address mobility option is included in the 817 Binding Revocation Indication. 819 o If the home agent needs to only revoke the mobile node's IPv4 home 820 address binding, the home agent MUST set the IPv4 HoA Binding Only 821 (V) bit and MUST include the mobile node's registered IPv4 home 822 address that is being revoked in the IPv4 Home Address option. 824 The Acknowledge (A) bit in the Binding Revocation Indication requests 825 the mobile node to return a Binding Revocation Acknowledgement in 826 response to this Binding Revocation Indication. As described in 827 Section 7.3, the home agent SHOULD retransmit this Binding Revocation 828 Indication to the mobile node before terminating its IP connection 829 until it receives a matching Binding Revocation Acknowledgement or 830 the BRIMaxRetransmitNumber has been reached. 832 When the home agent sends a BRI to the mobile node with the (A) bit 833 set, the home agent sets a flag in the mobile node BCE to indicate 834 that revocation is in progress and starts the MINDelayBRIs timer. 835 The home agent maintains the mobile node BCE in this state until it 836 receives a Binding Revocation Acknowledgement or the 837 BRIMaxRetransmitNumber is reached. 839 In a race condition case, the home agent may receive a BU from the 840 mobile node while the mobile node's BCE has the revocation in 841 progress flag set, the home agent SHOULD handle this case based on 842 the reason for sending the Binding Revocation Indication message and 843 its local policy. In this case, if the home agent accepts the BU, it 844 needs to update the mobile node BCE accordingly, e.g. removing the 845 revocation in progress flag. 847 When the home agent needs to revoke one or more of a mobile node 848 bindings that were created using Multi Care-of address registration 849 as in [ID-MCoA], the home agent MUST include all the related Binding 850 ID options that identify these bindings in the Binding Revocation 851 Indication message. In the case when the home agent needs to revoke 852 all of the mobile node bindings, the home agent MUST NOT include any 853 of the Binding ID options. 855 8.2. Receiving Binding Revocation Acknowledgement 857 When the home agent receives a packet carrying a valid BRA that was 858 successfully processed as in Section 7.2, the home agent SHOULD 859 examine the Status field as follows: 861 o If the Status field indicates that the Binding Revocation 862 Indication was processed successfully, the home agent deletes the 863 MINDelayBRIs timer and the mobile node bindings and all related 864 resources. 866 o If the Status field indicates any value other than success, the 867 home agent SHOULD examine any mobility options included in the 868 Binding Revocation Acknowledgement. The home agent MAY log the 869 appropriate event to reflect the status of the received BRA. 871 9. Local Mobility Anchor Operation 873 9.1. Binding Revocation Initiator 875 9.1.1. Sending Binding Revocation Indication 877 To terminate a mobile node proxy mobile IPv6 registration and its 878 current PMIPv6 binding with the local mobility agent, the LMA sends a 879 packet to the MAG containing a BRI message following the procedure in 880 Section 7.1 and the following rules: 882 o The Acknowledge (A) bit MAY be set in the Binding Revocation 883 Indication to request the mobile access gateway to send a Binding 884 Revocation Acknowledgement upon receipt of the BRI. 886 o The Proxy Mobile IP (P) bit MUST be set in the BRI message to 887 indicate that the binding being revoked is a proxy Mobile IPv6 888 binding. 890 o The Revocation Trigger field MUST be set in the Binding Revocation 891 Indication to indicate to the mobile access gateway the reason for 892 removing the specified mobile node proxy mobile IPv6 binding at 893 the LMA. The Revocation Trigger may be used by the mobile access 894 gateway to learn the mobile node's latest movement. 896 o In case of revoking all Per-Peer bindings, the Global (G) bit MUST 897 be set and the Revocation Trigger MUST contain a value of "Per- 898 Peer Policy" in the Binding Revocation Indication to request the 899 mobile access gateway to remove all Per-Peer bindings that are 900 registered with the LMA and hosted at this MAG. 902 o Whenever the Global (G) bit is set in the BRI, the Acknowledge (A) 903 bit MUST be set to request the mobile access gateway to send a 904 Binding Revocation Acknowledgement upon receipt of the BRI. 906 o The packet MUST contain the Mobile Node Identifier, MN-ID, option 907 which contains the mobile node's NAI that was used in the proxy 908 Binding Update during the mobile node registration. 910 o If the Mobile Node Identifier, MN-ID, is registered in more than 911 one of the mobile node's BCE and the LMA does NOT need to revoke 912 all of the mobile node's bindings, the packet MUST contain another 913 identifier to uniquely identify the mobile node binding(s) that is 914 being revoked, e.g., at least one Home Network Prefix option which 915 contains the mobile node's registered HNP for the binding being 916 revoked. 918 o The care-of address for the binding MAY be used as the destination 919 address in the packet's IPv6 header, unless an Alternate Care-of 920 Address mobility option is included in the Binding Revocation 921 Indication message. 923 The Acknowledge (A) bit in the Binding Revocation Indication requests 924 the mobile access gateway to return a Binding Revocation 925 Acknowledgement in response to this Binding Revocation Indication. 926 As described in Section 7.3, the LMA SHOULD retransmit this BRI to 927 the MAG before deleting the mobile node IP tunnel to the mobile 928 access gateway until it receives a matching Binding Revocation 929 Acknowledgement or the BRIMaxRetransmitNumber is reached. The local 930 mobility anchor MAY delete the mobile node(s) IP tunnel immediately 931 after sending the Binding Revocation Indication and before receiving 932 the BRA message. 934 When the local mobility anchor sends a Binding Revocation Indication 935 to the mobile access gateway to remove a specific binding and the 936 Acknowledge (A) bit is set in the BRI, the local mobility anchor sets 937 a flag in the mobile node proxy BCE to indicate that revocation is in 938 progress and starts the MINDelayBRIs timer. The local mobility 939 anchor SHOULD maintain the mobile node proxy BCE in this state until 940 it receives a Binding Revocation Acknowledgement or the 941 BRIMaxRetransmitNumber is reached. In the case when the local 942 mobility anchor sets the Revocation Trigger field to a value which 943 indicate inter-MAG handover, the local mobility anchor MAY switch the 944 mobile node IP tunnel to the target mobile access gateway before 945 sending a Binding Revocation Indication to the sources mobile access 946 gateway. 948 In a race condition case, the local mobility anchor may receive a PBU 949 from the mobile access gateway while the mobile node's proxy BCE has 950 the revocation in progress flag set, the LMA should handle this case 951 based on the reason for sending the Binding Revocation Indication 952 message and its local policy. In this case, if the LMA accepts the 953 PBU, it needs to update the mobile node proxy BCE accordingly, e.g. 954 removing the revocation in progress flag. 956 When the local mobility anchor needs to revoke all mobile nodes proxy 957 BCE that are registered with the local mobility anchor and hosted at 958 the mobile access gateway, the LMA MUST set the Global (G) bit and 959 the value of the Revocation Trigger field to "Per-Peer Policy". In 960 this case, the LMA MUST NOT include any mobility options in the BRI. 962 When the LMA needs to revoke all mobile nodes proxy BCE that belong 963 to a specific realm, e.g. @companyabc.com, and are registered with 964 the LMA and hosted at the MAG, the local mobility anchor MUST set the 965 Global (G) bit and the value of the Revocation Trigger field to 966 "Revoking Mobility Node Local Policy". In this case, the local 967 mobility anchor MUST include a mobility option to identify the 968 impacted bindings, e.g. MN-ID option with a wildcard NAI, e.g. 969 *@companyabc.com, to identify all the mobile nodes BCEs that need to 970 be removed. 972 When the mobile node is registered with multiple Home Network 973 Prefixes for the same proxy care-of address, the local mobility 974 anchor SHOULD include a HNP option for each registered HNP in the 975 BRI. Alternatively, the LMA MAY include only the mobile node 976 identifier, MN-ID, option in the BRI to indicate to the mobile access 977 gateway to remove all bindings of the specified mobile node NAI in 978 the MN-ID option. 980 When the mobile node is registered with an IPv4 proxy home address in 981 addition to the Home Network Prefix where both of the IPv4 pHoA and 982 HNP are bound to the same proxy CoA, the local mobility anchor MAY 983 revoke the mobile node IPv4 proxy HoA binding to the current mobile 984 node proxy CoA while maintaining the mobile node binding of the HNP 985 to its current pCoA as part of the mobile node BCE. In this case, if 986 the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the 987 LMA MUST send a BRI message following the procedure in Section 7.1 988 and the following rules: 990 o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to 991 indicate that only the IPv4 home address binding is being revoked. 993 o The Acknowledge (A) bit MUST be set in the BRI to request the MAG 994 to send a BRA message. 996 o The IPv4 Home Address option MUST be included with the mobile 997 node's registered IPv4 home address that is being released in 998 addition to the MN-ID option. 1000 o The mobile node Home Network Prefix option MUST NOT be included. 1002 o The Revocation Trigger field MUST be set to an appropriate value, 1003 e.g. "IPv4 Address Lease Expired". 1005 9.1.2. Receiving Binding Revocation Acknowledgement 1007 When the local mobility anchor receives a packet carrying a valid 1008 Binding Revocation Acknowledgement that was successfully processed as 1009 in Section 7.2 and if the mobile node BCE is in the state of 1010 Revocation in progress, the local mobility anchor SHOULD examine the 1011 Status field before clearing the mobile node related resources as 1012 follows: 1014 o If the Status field indicates that the BRI was processed 1015 successfully, the local mobility anchor delete the MINDelayBRIs 1016 timer and the mobile node proxy bindings and all associated 1017 resources. 1019 o If the Status field indicates partial success value or MN binding 1020 does not exist, the local mobility anchor SHOULD examine mobility 1021 options that are included in the Binding Revocation 1022 Acknowledgement, if any, before deleting the MINDelayBRIs timer 1023 and the mobile node associated proxy bindings and all related 1024 resources. It is based on the LMA local policy how to handle the 1025 mobile node BCE(s) that the mobile access gateway indicated it 1026 failed the revocation procedure, however, the LMA MAY log the 1027 event. 1029 9.2. Binding Revocation Responder 1031 9.2.1. Receiving Binding Revocation Indication 1033 When the local mobility anchor receives a packet carrying a Binding 1034 Revocation Indication that was successfully processed as in 1035 Section 7.2, the local mobility anchor SHOULD in addition process the 1036 message as follows: 1038 o Binding Revocation Indication is formatted as in Section 6.1 and 1039 if the (P) bit is set, the local mobility anchor MUST validate 1040 that all impacted binding(s) have the proxy binding flag set. 1042 o If the Global (G) bit is set and the Revocation Trigger value is 1043 "Per-Peer Policy", the Proxy (P) bit MUST be set and the BRI 1044 SHOULD contain the mobile access gateway ID in the MN-ID option. 1045 The local mobility anchor MUST verify that the identified mobile 1046 access gateway as per the value in the MN-ID option is authorized 1047 to use the Global revocation. The mechanism the LMA uses to 1048 verify the MAG authorization is out of scope of this document. 1050 o If the Global (G) bit is set and the Revocation Trigger value is 1051 "Per-Peer Policy", and only the mobile node identifier, MN-ID, 1052 option is included, the local mobility anchor MUST revoke all 1053 mobile nodes bindings which proxy CoA is the one used as the 1054 source of the IPv6 packet that carried the BRI. However, if one 1055 or more Alternate Care-of Address options are included in addition 1056 to the mobile node identifier option in the BRI message, the local 1057 mobility anchor MUST revoke all mobile nodes bindings which proxy 1058 Care-of Address matches one of the Care-of address(es) in the 1059 Alternate Care-of Address option(s). 1061 o If the Global (G) bit is set and the Revocation Trigger value is 1062 "Per-Peer Policy", and the mobile node identifier, MN-ID, option 1063 is NOT included, the local mobility anchor MUST reject the BRI 1064 message by sending a BRA message with the status field is set to 1065 "Global Revocation Authorization Required". 1067 o The LMA identifies all impacted mobile nodes bindings and if the 1068 Acknowledgement (A) bit is set, the local mobility anchor MUST 1069 send a Binding Revocation Acknowledgement following Section 9.2.2 1070 using the appropriate status code. 1072 o If the Global (G) bit is NOT set, the local mobility anchor SHOULD 1073 use the included mobility options to identify the impacted mobile 1074 node binding as follows: 1076 1. If only the mobile node identifier, MN-ID, option is included, 1077 the local mobility anchor MUST revoke all bindings for this 1078 mobile node which use the specified mobile node NAI. 1080 2. If the mobile node identifier, MN-ID, and the Home Network 1081 Prefix option are included, the local mobility anchor MUST 1082 only remove the specified proxy binding. 1084 3. If the mobile node identifier, MN-ID, option and more than one 1085 Home Network Prefix options are included, the local mobility 1086 anchor MUST remove all bindings which are referenced by these 1087 multiple Home Network Prefixes for the specified mobile node 1088 NAI. 1090 The Revocation Trigger field value in the received Binding Revocation 1091 Indication could be used by the local mobility anchor to log an event 1092 or update some local parameters which tracks the state of the peer 1093 mobile access gateway. 1095 9.2.2. Sending Binding Revocation Acknowledgement 1097 When the local mobility anchor receive a valid Binding Revocation 1098 Indication with the (A) bit set and after processing the BRI message, 1099 the local mobility anchor sends a packet to the mobile access gateway 1100 containing a Binding Revocation Acknowledgement following the process 1101 in Section 7.1 and the following: 1103 o If the (P) bit was set in the received Binding Revocation 1104 Indication, the local mobility anchor MUST set the (P) bit in the 1105 BRA. 1107 o If the Global (G) bit was set in the received BRI, the local 1108 mobility anchor MUST set the (G) bit in the Binding Revocation 1109 Acknowledgement. 1111 o If the IPv4 HoA Binding Only (V) bit was set in the received BRI, 1112 the local mobility anchor MUST set the (V) bit in the Binding 1113 Revocation Acknowledgement. 1115 o The local mobility anchor MUST set the status field to a valid 1116 code that reflects the processing of the received Binding 1117 Revocation Indication. If the mobile access gateway is not 1118 authorized to use the Per-Peer Global revocation feature, the LMA 1119 MUST set the status field to (Global Revocation NOT Authorized). 1121 o In the case that one of the bindings identified in the received 1122 BRI message has already been released before receiving the BRI, 1123 the LMA MAY set the status field to partial success and in this 1124 case it MAY include the mobile node identifier or the Home Network 1125 Prefix option to identify the binding(s) that failed revocation. 1127 o The destination IP address of the IPv6 packet of the Binding 1128 Revocation Acknowledgement is set to the source IP address of the 1129 received BRI. 1131 10. Mobile Access Gateway Operation 1133 10.1. Binding Revocation Responder 1135 10.1.1. Receiving Binding Revocation Indication 1137 Upon receiving a packet carrying a Binding Revocation Indication, the 1138 mobile access gateway MUST validate the packet according to 1139 Section 7.2 and the following: 1141 o BRI MUST be formatted as in Section 6.1 and the (P) bit is set. 1143 o If the Acknowledgement (A) bit in the received BRI is set, the 1144 mobile access gateway MUST send a Binding Revocation 1145 Acknowledgement following Section 10.1.2 using the appropriate 1146 status value. 1148 o If the Global (G) bit is set and the Revocation Trigger field is 1149 set to "Per-Peer policy", the mobile access gateway identifies all 1150 bindings that are registered at the LMA and hosted at the MAG. 1151 This Binding Revocation Indication does not include any other 1152 mobility options. In this case, the MAG MUST send a BRA with the 1153 appropriate status code to the LMA. 1155 o If the Global (G) bit is set and the Revocation Trigger field is 1156 set to "Revoking Mobility Node Local Policy", the MAG MUST 1157 identify all bindings that are registered at the LMA and hosted at 1158 the MAG using the mobility option(s) included in the BRI. This 1159 Binding Revocation Indication SHOULD include at least the MN-ID 1160 option, e.g. with a wild card NAI. In this case, the MAG MUST 1161 send a BRA with the appropriate status code to the LMA. 1163 o If the Global (G) bit is set and the Revocation Trigger field is 1164 set to "Revoking Mobility Node Local Policy", and no mobility 1165 options are included in the Binding Revocation Indication message 1166 or the MAG is not able to identify the impacted mobile nodes 1167 bindings based on the included mobility options, the MAG MUST 1168 treat this as an error scenario. In this case, the MAG SHOULD 1169 send a Binding Revocation Acknowledgement message with status "CAN 1170 NOT Identify Binding". 1172 o If the Revocation Trigger field value in the received Binding 1173 Revocation Indication message indicates an inter-MAG handover and 1174 the (A) bit is set, the MAG use the mobility option(s) included in 1175 the BRI message to identify the mobile node binding. The mobile 1176 access gateway MAY validate that the mobile node is no longer 1177 attached to the mobile access gateway before sending a successful 1178 Binding Revocation Acknowledgement message to the LMA. However, 1179 if the Revocation Trigger field is set to "Inter-MAG - Unknown 1180 Handoff" or "Possible Out-of Sync BCE State" and the (A) bit is 1181 set, the MAG MUST validate that the mobile node is no longer 1182 attached to the MAG before sending a successful BRA message and 1183 deleting the resources associated with the mobile node binding. 1184 Otherwise, if the MAG verified that the MN is still attached, the 1185 MAG MUST set the status field in the BRA to "Revocation failed - 1186 MN is attached". 1188 o If the IPv4 HoA Binding Only (V) bit in the received BRI message 1189 is set, the MAG uses the MN-ID option to identify the mobile node 1190 binding entry in the BUL. The MAG MUST verify that the IPv4 1191 address included in the IPv4 Home Address option in the received 1192 BRI is the same as the IPv4 proxy HoA that is assigned to the 1193 mobile node. After the MAG successfully validates the received 1194 IPv4 home address as the mobile node IPv4 HoA, the MAG MUST 1195 consider this as an indication to release the mobile node IPv4 1196 proxy HoA binding to the mobile node current proxy CoA ONLY. 1197 Consequently, the MAG MUST continue to maintain the mobile node 1198 IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA 1199 as part of the mobile node binding in the BUL entry and release 1200 all resources associated with the MN IPv4 proxy HoA binding to the 1201 MN pCoA. In this case, the MAG MUST send a BRA message with the 1202 status field is set to success. On the other hand, if the MAG is 1203 able to identify the mobile node binding using the MN-ID but 1204 failed to identify the received IPv4 proxy HoA, the MAG MUST send 1205 a BRA with status field is set to "IPv4 HoA Binding Does NOT 1206 Exist". 1208 The Revocation Trigger field value in the received BRI could be used 1209 by the mobile access gateway to define what actions the MAG could do 1210 to inform the mobile node that its IP connectivity to the current HNP 1211 has been terminated, e.g., if the Revocation Trigger field is set to 1212 "Administrative Reason", the mobile access gateway may send a RA 1213 message after setting the Home Network Prefix lifetime to zero. 1215 10.1.2. Sending Binding Revocation Acknowledgement 1217 When the mobile access gateway receive a valid Binding Revocation 1218 Indication with the (A) bit set and after processing the BRI message, 1219 the mobile access gateway sends a packet to the local mobility anchor 1220 containing a Binding Revocation Acknowledgement according to the 1221 procedure in Section 7.1 and the following: 1223 o The mobile access gateway MUST set the (P) bit in the Binding 1224 Revocation Acknowledgement if it is set in the received BRI. 1226 o If the Global (G) bit was set in the received BRI, the mobile 1227 access gateway MUST set the (G) bit in the Binding Revocation 1228 Acknowledgement. 1230 o If the IPv4 HoA Binding Only (V) bit was set in the received BRI, 1231 the mobile access gateway MUST set the (V) bit in the Binding 1232 Revocation Acknowledgement. 1234 o The mobile access gateway MUST set the status field to a valid 1235 code that reflects the processing of the received Binding 1236 Revocation Indication. 1238 o In the case that one or more of the bindings identified in the 1239 received BRI message has already been released before receiving 1240 the BRI, the mobile access gateway MAY set the status field to 1241 partial success and in this case it MAY include the mobile node 1242 identifier, MN-ID, or the Home Network Prefix option to identify 1243 the binding(s) that failed to be removed as part of the revocation 1244 procedure. 1246 o The destination IP address of the IPv6 packet of the Binding 1247 Revocation Acknowledgement is set to the source IP address of the 1248 received Binding Revocation Indication. 1250 10.2. Binding Revocation Initiator 1252 10.2.1. Sending Binding Revocation Indication 1254 The mobile access gateway could send a Binding Revocation Indication 1255 message to indicate the termination of multiple mobile node bindings, 1256 e.g., when using the global revocation with the Global (G) bit set. 1257 In this case when an event occurs which requires the mobile access 1258 gateway to inform the LMA to terminate all mobile nodes bindings that 1259 are registered at the local mobility anchor and the mobile access 1260 gateway, the mobile access gateway sends a Binding Revocation 1261 Indication message following Section 7.1 and the following: 1263 o The Acknowledge (A) bit MUST be set in the Binding Revocation 1264 Indication to request the local mobility anchor to send a Binding 1265 Revocation Acknowledgement upon receipt of the BRI. 1267 o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation 1268 Indication to indicate that bindings that being revoked is a proxy 1269 Mobile IPv6 binding. 1271 o The Global (G) bit MUST be set and the Revocation Trigger contains 1272 a value of "Per-Peer Policy" in the Binding Revocation Indication 1273 to request the LMA to remove all Per-Peer bindings that are 1274 registered with the LMA and hosted at this MAG. In this case, the 1275 MN-ID option MUST be included in the BRI and contains the mobile 1276 access gateway identity. In this case the mobile access gateway 1277 MAY include one or more Alternate Care-of Address option(s). The 1278 Alternate Care-of Address option(s) include the proxy Care-of 1279 address(es) which their bindings are being impacted by this BRI 1280 message. 1282 o The mobile access gateway address MAY be used as the Source 1283 Address in the packet's IPv6 header. 1285 The Acknowledge (A) bit in the Binding Revocation Indication requests 1286 the local mobility anchor to return a BRA in response to this Binding 1287 Revocation Indication. As described in Section 7.3, the mobile 1288 access gateway SHOULD retransmit this BRI to the local mobility 1289 anchor until it receives a matching BRA or the BRIMaxRetransmitNumber 1290 is reached. The mobile access gateway MAY delete the mobile nodes IP 1291 tunnels immediately after sending the Binding Revocation Indication 1292 before receiving a BRA message from the LMA. 1294 10.2.2. Receiving Binding Revocation Acknowledgement 1296 When the mobile access gateway receives a packet carrying a valid 1297 Binding Revocation Acknowledgement that was successfully processed 1298 according to Section 7.2, the mobile access gateway MUST process the 1299 BRA as per the followings: 1301 o When the mobile access gateway receives a packet carrying a valid 1302 Binding Revocation Acknowledgement and the Global (G) and Proxy 1303 MIPv6 (P) bits are set and the mobile nodes BCEs are in the state 1304 of Revocation in Progress, the mobile access gateway SHOULD 1305 examine the Status field as follows: 1307 o If the Status field indicates that the Binding Revocation 1308 Indication was processed successfully, the mobile access gateway 1309 delete the MINDelayBRIs timer and the mobile nodes proxy bindings 1310 and all associated resources. 1312 o If the Status field indicates (Global Revocation NOT Authorized), 1313 the mobile access gateway is not authorized to participate in a 1314 Per-Peer Global Revocation. The mobile access gateway SHOULD NOT 1315 retry sending a Binding Revocation Indication with the Global (G) 1316 bit is set to the same local mobility agent. The mobile access 1317 gateway should raise an alarm or log an event to indicate this 1318 rejection. 1320 11. Mobile Node Operation 1322 11.1. Receiving Binding Revocation Indication 1324 Upon receiving a packet carrying a Binding Revocation Indication, the 1325 mobile node MUST validate the packet according to Section 7.2 and the 1326 following tests: 1328 o The mobile node MUST verify that the IP address in the type 2 1329 routing header is its Home Address and that its Binding Update 1330 List contains an entry for that Home Address. If one of the 1331 tests, fails the mobile node SHOULD silently discard the received 1332 BRI message. 1334 o If the Acknowledgement (A) bit is set in the Binding Revocation 1335 Indication and its Binding Update List contains an entry for the 1336 IP address in the type 2 routing header, the mobile node MUST send 1337 a Binding Revocation Acknowledgement. However, in all other cases 1338 when the (A) bit is set in the BRI, the mobile node SHOULD send a 1339 Binding Revocation Acknowledgement. In all cases, the mobile node 1340 MUST follow Section 11.2 and send a BRA using the appropriate 1341 status code. 1343 o If the IPv4 HoA Binding Only (V) bit is set in the received BRI 1344 message, the MN MUST verify that there is an IPv4 Home Address 1345 option in the received BRI and the IPv4 address included in the 1346 IPv4 Home Address option is the same as its IPv4 HoA that is 1347 assigned to the mobile node. If this verification is successful, 1348 the MN MUST consider this BRI as an indication to release the 1349 mobile node IPv4 HoA binding ONLY to its current Care-of Address. 1350 Consequently, the MN MUST continue to maintain its IPv6 HoA 1351 binding to the current CoA as part of the mobile node binding in 1352 the BUL entry and release all resources associated with the MN 1353 IPv4 HoA binding. In this case, the MN MUST send a BRA message 1354 with the status field is set to success. On the other hand, if 1355 the IPv4 Home Address Option was NOT included in the received BRI 1356 with the (V) bit set, the MN SHOULD send a BRA message with the 1357 status field set to "IPv4 Home Address Option Required". 1358 Additionally, if the IPv4 HoA received in the IPv4 Home Address 1359 Option is NOT the one assigned to the MN, the MN SHOULD send a BRA 1360 with the status field set to "IPv4 HoA Binding Does NOT Exist". 1362 o The mobile node MUST verify that the (P) bit in the Binding 1363 Revocation Indication is NOT set. If the (P) bit is set, the 1364 mobile node MUST silently discard the Binding Revocation 1365 Indication message. 1367 o If the mobile node has registered multiple care-of addresses with 1368 its home agent, the mobile node MUST verify which binding is being 1369 revoked by examining the content of the BRI message. If the 1370 mobile node received a Binding Revocation Indication with a single 1371 or more than one Binding ID options and its home address is 1372 included in the type 2 routing header, the mobile node MUST 1373 consider all of the care-of address(es) binding(s), identified in 1374 the Binding ID options, with this home address are being revoked. 1376 o If the mobile node has multi Care-of Addresses bindings with its 1377 home agent and received a Binding Revocation Indication, without 1378 any Binding ID option included and its home address was included 1379 in the type 2 routing header, the mobile node MUST consider all of 1380 its registered care-of addresses bindings with this home address 1381 are being revoked. 1383 The Revocation Trigger field value in the received Binding Revocation 1384 Indication could be used by the mobile node to define what action the 1385 mobile node could do to be able to register again and receive its IP 1386 mobility service, e.g. contacting its home operator. 1388 11.2. Sending Binding Revocation Acknowledgement 1390 When the mobile node receives a Binding Revocation Indication from 1391 its home agent, the mobile node processes the received BRI as in 1392 Section 11.1. If the mobile node is required to send a BRA message 1393 in response to the received BRI, the mobile node sends a packet to 1394 its home agent containing a Binding Revocation Acknowledgement 1395 according to the procedure in Section 7.1 and the following: 1397 o The mobile node MUST set the status field to an appropriate value. 1398 The mobile node sets the status field to success to reflect that 1399 it has received the Binding Revocation Indication and acknowledge 1400 that its IP connectivity with its home agent has been revoked. 1402 o The destination IP address of the IPv6 packet of the Binding 1403 Revocation Acknowledgement is set to the source IP address of the 1404 received IPv6 packet of the Binding Revocation Indication. The 1405 Mobile Node MUST include its home address in the Home Address 1406 Destination Option. 1408 12. Protocol Configuration Variables 1410 Any mobility entity which is allowed to invoke the binding revocation 1411 procedure by sending a Binding Revocation Indication message SHOULD 1412 allow the following variables to be configured. 1414 BRI Maximum Number of Retries (BRIMaxRetriesNumber) 1416 This variable specifies the maximum Number of times a mobility 1417 entity can retransmit a Binding Revocation Indication message 1418 before receiving a Binding Revocation Acknowledgement message. 1419 The default value for this parameter is 1. 1421 Minimum Delay Between BRI messages (MINDelayBRIs) 1423 This variable specifies the delay time in seconds before the 1424 revoking mobility entity retransmits a BRI message. The default 1425 is 1 second but not less than 0.5 seconds. 1427 13. IANA Considerations 1429 This document defines a new Binding Revocation Message using a new 1430 Mobility Header Type , as described in Section 6. The new 1431 Mobility Header type value needs to be assigned from the same 1432 numbering space as allocated for the other Mobility Header types. 1434 This document also creates a new name space "Binding Revocation Type" 1435 which indicates the type of the binding revocation message. The 1436 current binding revocation message types are described in Section 6.1 1437 and Section 6.2, and are the following: 1439 0 Reserved 1440 1 Binding Revocation Indication 1441 2 Binding Revocation Acknowledgement 1442 All other values are reserved 1444 Future values of the Binding Revocation Type can be allocated using 1445 Standards Action or IESG Approval [RFC2434]. 1447 In addition, this document also creates a second new namespace for 1448 the Binding Revocation Trigger which indicates the reason behind 1449 sending the Binding Revocation Indication message. The current 1450 Binding Revocation Trigger values are described in Section 6.1, and 1451 are the following: 1453 Reserved and Per-MN Revocation Trigger Values: 1454 0 Reserved 1455 1 Unspecified 1456 2 Administrative Reason 1457 3 Inter-MAG Handoff - same Access Types 1458 4 Inter-MAG Handoff - different Access Types 1459 5 Inter-MAG - Unknown Handoff 1460 6 User Initiated Session(s) Termination 1461 7 Access Network Session(s) Termination 1462 8 IPv4 HoA Lease Expires 1463 9 Possible Out-of Sync BCE State 1464 250-255 Reserved For Testing Purposes only 1465 All other values are Reserved 1467 Global Revocation Trigger Values: 1468 128 Per-Peer Policy 1469 129 Revoking Mobility Node Local Policy 1471 Future values of the Binding Revocation Trigger can be allocated 1472 using Standards Action or IESG Approval [RFC2434]. 1474 Furthermore, this document creates a third new name space "Status 1475 Code" for the Status field in the Binding Revocation Acknowledgement 1476 message. The current values are described in Section 6.2, and are 1477 the following: 1479 0 success 1480 1 partial success 1481 128 Binding Does NOT Exist 1482 129 IPv4 HoA Binding Does NOT Exist 1483 130 IPv4 Home Address Option Required 1484 131 Global Revocation NOT Authorized 1485 132 CAN NOT Identify Binding 1486 133 Revocation Failed - MN is Attached 1488 Future values of the Status field can be allocated using Standards 1489 Action or IESG Approval [RFC2434]. 1491 All fields labeled "Reserved" are only to be assigned through 1492 Standards Action or IESG Approval. 1494 14. Security Considerations 1496 The protocol described here uses the same security association 1497 between the MN and the HA or the MAG and the LMA that has been used 1498 to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the 1499 session was established. If IPsec is used, the SPD of this IPsec SA 1500 MUST allow the MH type for the Binding Revocation Message defined in 1501 this document. 1503 However, in the case when the MAG sends a BRI message with the Global 1504 (G) bit is set and the Revocation Trigger field is set to "Per-Peer 1505 policy", the LMA MUST verify that the MAG is authorized to use Per- 1506 Peer Global Revocation. 1508 15. Acknowledgements 1510 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1511 Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay 1512 Devarapalli, and Joel Hortelius for their review and comments of this 1513 draft and all colleagues who have supported the advancement of this 1514 draft effort. 1516 16. References 1518 16.1. Normative References 1520 [ID-DSMIP6] 1521 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1522 Routers", draft-ietf-mext-nemo-v4traversal-07 (work in 1523 progress), December 2008. 1525 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1526 "Multiple Care-of Addresses Registration", 1527 draft-ietf-monami6-multiplecoa-11 (work in progress), 1528 January 2009. 1530 [ID-PMIP6-IPv4] 1531 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1532 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 1533 (work in progress), January 2009. 1535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1536 Requirement Levels", BCP 14, RFC 2119, March 1997. 1538 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1539 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1540 October 1998. 1542 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1543 in IPv6", RFC 3775, June 2004. 1545 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1546 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1547 (MIPv6)", RFC 4283, November 2005. 1549 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1550 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1552 16.2. Informative References 1554 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1555 August 2002. 1557 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1558 Mobile IPv4", RFC 3543, August 2003. 1560 Authors' Addresses 1562 Ahmad Muhanna 1563 Nortel 1564 2221 Lakeside Blvd. 1565 Richardson, TX 75082 1566 USA 1568 Email: amuhanna@nortel.com 1569 Mohamed Khalil 1570 Nortel 1571 2221 Lakeside Blvd. 1572 Richardson, TX 75082 1573 USA 1575 Email: mkhalil@nortel.com 1577 Sri Gundavelli 1578 Cisco Systems 1579 170 West Tasman Drive 1580 San Jose, CA 95134 1581 USA 1583 Email: sgundave@cisco.com 1585 Kuntal Chowdhury 1586 Starent Networks 1587 30 International Place 1588 Tewksbury, MA 01876 1589 USA 1591 Email: kchowdhury@starentnetworks.com 1593 Parviz Yegani 1594 Juniper Networks 1595 1194 North Mathilda Avenue 1596 Sunnyvale, CA 94089 1597 USA 1599 Email: pyegani@juniper.net