idnits 2.17.1 draft-ietf-mext-binding-revocation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1387. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o If the Revocation Trigger field value is Administrative, the mobile node MUST not try to re-register with the home agent before contacting its home operator. -- 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 (July 31, 2008) is 5747 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-04 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-08 == Outdated reference: A later version (-01) exists of draft-haley-mext-generic-signaling-message-00 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-03 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT WG A. Muhanna 3 Internet-Draft M. Khalil 4 Intended status: Standards Track Nortel 5 Expires: February 1, 2009 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Starent Networks 9 P. Yegani 10 Cisco Systems 11 July 31, 2008 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on February 1, 2009. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 This document defines the revocation semantics for terminating a 48 mobile node's mobility session and associated resources. These 49 semantics are generic enough and can be used by mobility entities in 50 the case of Client Mobile IPv6 and its extensions. This mechanism 51 allows the mobility entity which initiates the revocation procedure 52 to request its corresponding one to terminate either one, multiple or 53 all specified binding cache entries. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 59 2.1. Conventions used in this document . . . . . . . . . . . . 4 60 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 62 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 63 3.2. Client MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . 6 64 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 65 3.3.1. Termination of Multiple Care-of Addresses Bindings . . 7 66 3.3.2. Termination of All Care-of Addresses Bindings . . . . 8 67 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 68 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8 69 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 10 70 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings . . 10 71 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. Binding Revocation Messages . . . . . . . . . . . . . . . . . 10 73 5.1. Binding Revocation Indication Message . . . . . . . . . . 10 74 5.2. Binding Revocation Acknowledgement Message . . . . . . . . 13 75 6. Binding Revocation Process Considerations . . . . . . . . . . 15 76 6.1. Sending Binding Revocation Messages . . . . . . . . . . . 15 77 6.2. Receiving Binding Revocation Messages . . . . . . . . . . 15 78 6.3. Retransmission of Binding Revocation Indication . . . . . 16 79 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 16 80 7.1. Sending Binding Revocation Indication . . . . . . . . . . 16 81 7.2. Receiving Binding Revocation Acknowledgement . . . . . . . 18 82 8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 18 83 8.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 18 84 8.1.1. Sending Binding Revocation Indication . . . . . . . . 18 85 8.1.2. Receiving Binding Revocation Acknowledgement . . . . . 20 86 8.2. Binding Revocation Responder . . . . . . . . . . . . . . . 21 87 8.2.1. Receiving Binding Revocation Indication . . . . . . . 21 88 8.2.2. Sending Binding Revocation Acknowledgement . . . . . . 22 89 9. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 23 90 9.1. Binding Revocation Responder . . . . . . . . . . . . . . . 23 91 9.1.1. Receiving Binding Revocation Indication . . . . . . . 23 92 9.1.2. Sending Binding Revocation Acknowledgement . . . . . . 24 93 9.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 25 94 9.2.1. Sending Binding Revocation Indication . . . . . . . . 25 95 9.2.2. Receiving Binding Revocation Acknowledgement . . . . . 26 97 10. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 26 98 10.1. Receiving Binding Revocation Indication . . . . . . . . . 26 99 10.2. Sending Binding Revocation Acknowledgement . . . . . . . . 27 100 11. Protocol Configuration Variables . . . . . . . . . . . . . . . 28 101 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 102 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 103 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 104 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 106 15.2. Informative References . . . . . . . . . . . . . . . . . . 30 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 108 Intellectual Property and Copyright Statements . . . . . . . . . . 32 110 1. Introduction 112 In the case of Mobile IPv6 and for administrative reason, sometimes 113 it becomes necessary to inform the mobile node that its registration 114 has been revoked and the mobile node is no longer able to receive IP 115 mobility service using its Home Address. In some networks where 116 Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 117 registration revocation mechanism has been specified [RFC3543]. 119 This document defines the semantics of the revocation mechanism of a 120 mobile node registration binding, which could have been established 121 using a Client Mobile IPv6 or any of its extensions, e.g. Proxy 122 Mobile IPv6 signaling. The proposed revocation mechanism uses the 123 Mobile IPv6 Generic Signalling Message framework as defined in 124 [ID-MGSM] which has a generic message framework which is applicable 125 to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [ID-PMIP6] and can be 126 used by any two IP mobility entities. As an example, this mechanism 127 allows a local mobility agent, involved in providing IP mobility 128 services to a mobile node, to notify the mobility access gateway of 129 the termination of a mobile node binding registration. In another 130 example, a mobility access gateway can use this mechanism to notify 131 its local mobility anchor peer with a bulk termination of all Proxy 132 MIPv6 bindings that are registered with the local mobility anchor and 133 currently being served by the mobility access gateway. 135 2. Conventions & Terminology 137 2.1. Conventions used in this document 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2.2. Terminology 145 All the general mobility related terminology and abbreviations are to 146 be interpreted as defined in Mobile IPv6 specification [RFC3775] and 147 Proxy Mobile IPv6 specification [ID-PMIP6]. 149 3. Binding Revocation Protocol and Use Cases Overview 151 This specification defines a binding revocation mechanism using the 152 framework of Mobile IPv6 Generic Signaling Message (MGSM), where a 153 mobility node can communicate to the mobile node or another mobility 154 node the termination of the mobile node registration binding. The 155 following subsections describe the protocol overview and applicable 156 use cases. 158 3.1. Binding Revocation Protocol 160 In the case of Client Mobile IPv6, the revocation procedure can be 161 initiated by the home agent. If the home network decides to 162 terminate the service of the mobile node, the home agent sends a 163 Binding Revocation Indication (BRI) message to the mobile node. The 164 home agent includes the HoA option as specified in [RFC3775] to 165 indicate the impacted mobile node session. When the mobile node 166 receives a BRI message with its HoA included and the Acknowledge (A) 167 bit is set, the mobile node responds by sending a Binding Revocation 168 Acknowledgement (BRA) message. 170 In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also 171 be initiated by the home agent. If the home network decides to 172 terminate the service of the mobile node, the home agent sends a BRI 173 message to the mobile node to indicate the termination the mobile 174 node IP Mobility service. The home agent may include the HoA option 175 with the mobile node assigned home IPv4 address. After receiving the 176 BRI message with the Acknowledge (A) bit is set, the mobile node 177 responds by sending a BRA message. 179 Similarly, in the case of Proxy Mobile IPv6 [ID-PMIP6], the 180 revocation procedure can be initiated by the local mobility anchor by 181 sending a BRI message to communicate the termination of a mobile node 182 registration binding to the mobility access gateway. In this case, 183 the local mobility anchor includes the mobile node Home Network 184 Prefix option [ID-PMIP6] and the MN-ID option [RFC4283] to indicate 185 to the mobility access gateway the identity of the PMIPv6 binding 186 that needs to be terminated. When the mobility access gateway 187 receives the BRI message with the (A) bit set, the mobility access 188 gateway responds to the local mobility anchor by sending a BRA 189 message. 191 On the other hand, the mobility access gateway usually sends a de- 192 registration message by sending a Proxy BU with a lifetime of zero to 193 indicate to the local mobility anchor of the termination of the 194 PMIPv6 mobile node binding registration. In this case, the mobility 195 access gateway include the MN home network prefix option and the 196 MN-ID option as per [ID-PMIP6] in order for the local mobility anchor 197 to identify the mobile node PMIPv6 binding. However, in the case 198 when the mobility access gateway communicates a bulk termination of 199 PMIPv6 sessions, the mobility access gateway sends a BRI message with 200 the G bit set and includes the mobility access gateway identity in 201 the MN-ID option. When the local mobility anchor receives such BRI 202 message, it ensures that the mobility access gateway is authorized to 203 send such bulk termination message and then process the BRI message 204 accordingly. If the local mobility anchor processes the BRI message 205 successfully and the (A) bit is set in the BRI, the local mobility 206 anchor responds to the mobile access gateway by sending a BRA 207 message. Additionally, the initiator of the binding revocation 208 procedure include an indication in the Revocation Trigger field to 209 indicate to the receiving node the cause for the revocation 210 procedure. 212 3.2. Client MIPv6 and DSMIP6 Use Case 214 Binding revocation mechanism is applicable to Client Mobile IPv6 and 215 DSMIPv6 session when the home agent needs to inform the mobile node 216 that its binding registration has been revoked, e.g. for an 217 administrative reason. This mechanism enables the home domain to 218 dynamically allow the user to act upon the revocation message in 219 order to not have an unexpectedly interrupted mobile IPv6 services. 221 In this case, the home agent sends a BRI message to indicate to the 222 mobile node that its current mobile IPv6 binding has been revoked and 223 it no longer can receive IP mobility service. The home agent 224 includes the mobile node home address in HoA option, in the 225 destination option header as used in [RFC3775] and sets the 226 Revocation Trigger field to a proper value, e.g. Administrative. In 227 the case of DSMIPv6 session, the home agent may additionally include 228 the mobile node assigned IPv4 Home Address Option . When the mobile 229 node receives the BRI message, it sends a BRA message as described in 230 Section 10.2 to the home agent. Figure 1 illustrates the message 231 sequencing when home agent revokes a mobile node binding 232 registration. 234 MN HA 235 | | 236 | HoA in Dest. Opt. Hdr + BRI[seq.#, A bit] | 237 |<------------------------------------------| 238 | | 239 | | 240 | | 241 | BRA[seq.#] | 242 |------------------------------------------>| 243 | | 244 | | 246 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 248 3.3. Multi-Care of Addresses (Monami6) Use Case 250 In the case of Monami6 protocol, a mobile node is able to register 251 multiple care-of addresses for the same home address [ID-MCoA]. 252 Binding revocation mechanism is applicable to Monami6 when the home 253 agent sends a BRI message to revoke a single or more care-of address 254 bindings. 256 3.3.1. Termination of Multiple Care-of Addresses Bindings 258 In the case of multiple care-of addresses, the home agent maintains 259 different binding for each pair of care-of address and home address. 260 These bindings are also indexed and identified during the mobile node 261 registration using a new Binding ID mobility option [ID-MCoA]. In 262 this case, the home agent may revoke any binding, more than one 263 binding, or all of the bindings for the same mobile node home 264 address. 266 In the case when home agent revokes a single binding for a mobile 267 node with multiple care-of addresses registration, the home agent 268 send a BRI message to the mobile node with the corresponding BID 269 option included and the HoA option in the destination option header. 270 If the home agent needs to revoke more than one of the mobile node 271 registered care-of addresses, the home agent includes all the 272 corresponding BID options which reference these care-of addresses in 273 the same BRI message. Figure 2 illustrates the message flow when the 274 home agent revokes two registered Care-of addresses for the same MN 275 in a single BRI message. The home agent can revoke any registered 276 bindings by sending a BRI message to the respective mobile node. 278 HA Binding Cache 279 ================ 280 MN-BID1 [CoA1+HoA] 281 MN HA MN-BID2 [CoA2+HoA] 282 | | MN-BID3 [CoA3+HoA] 283 | BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA] 284 |<------------------------------------------| 285 | | 286 | | 287 | | 288 | BRA [seq.#, Cause] | 289 |------------------------------------------>| 290 | | 291 | | 293 Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings 295 3.3.2. Termination of All Care-of Addresses Bindings 297 The home agent may revoke all of the mobile node registered bindings, 298 by sending a BRI message without including any BID options while the 299 HoA option is included in the destination options header. Figure 1 300 illustrates the message flow when the home agent revokes all 301 registered Care-of addresses bindings for a MN in a single BRI 302 message. 304 3.4. Proxy MIPv6 Use Case 306 Since the Mobile node does not participate in the mobility mechanism 307 in the case of PMIPv6, there are many scenarios where Binding 308 Revocation mechanism is needed to clean resources and make sure that 309 the mobility entities, e.g. MAG and LMA, are always synchronized 310 with the status of the existing proxy mobile IPv6 bindings. The 311 binding revocation mechanism is generic enough that can be used in 312 all applicable PMIPv6 scenarios and deployment options. For example, 313 this revocation mechanism is still applicable and can be used when 314 PMIPv6 is deployed with IPv6 or IPv4 transports and when the mobile 315 node uses IPv4 or IPv6 address as specified in [ID-PMIP6-IPv4]. 317 When the mobile access gateway receives a BRI message as in 318 Section 9.1.1, the mobile access gateway sends a BRA message to the 319 local mobility anchor following the rules describes in Section 9.1.2. 320 Similarly if the local mobility anchor receives a BRI message with 321 the A bit is set, the local mobility anchor responds to the mobile 322 access gateway by sending a BRA message. 324 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding 326 The local mobility anchor may send a BRI message to the mobile access 327 gateway, hosting a specific proxy mobile IPv6 session, with the 328 appropriate value in the revocation trigger field to indicate that 329 the mobile node binding has been terminated and the mobile access 330 gateway can clean up the applicable resources. When the mobile 331 access gateway receives a BRI message, the MAG identify the respected 332 binding and if the A bit was set in the received BRI message, the MAG 333 sends a BRA message to the LMA. In this case, the MAG could send a 334 Router Advertisement message to the MN with the home network prefix 335 lifetime is set to zero. 337 As an example, Figure 3, illustrates the message sequence for 338 revoking a mobile node binding at the source MAG during the MN inter- 339 MAG handoff. During the inter-MAG handoff, the mobile node moves 340 from the source MAG to the target MAG. The target MAG sends a PBU 341 with the new care-of-address to the LMA to update the mobile node 342 point of attachment. Since the MN binding at the LMA points to the 343 source MAG and upon receiving the PBU from the target MAG, LMA 344 updates the MN BCE and send a PBA to the target MAG. LMA can send a 345 BRI message with the appropriate revocation trigger value, e.g. 346 inter-MAG handoff indication, to the source MAG in order to clean up 347 the applicable resources reserved for the specified MN. The MAG 348 acknowledges the BRI message by sending a BRA message to indicate the 349 success or failure of the termination of the mobile node binding. 351 The process identified above can also be used by the LMA in scenarios 352 other than the inter-MAG handoff with the proper revocation trigger 353 value to indicate to the peer MAG that a specific proxy mobile IPv6 354 binding or bindings have been revoked. 356 sMAG tMAG LMA 357 | | | 358 | | PBU | 359 | |--------------------------->| 360 | | PBU triggers 361 | | BRI Msg to sMAG 362 | | | 363 | | PBA | 364 | |<---------------------------| 365 | | | 366 | | | 367 | BRI [seq.#, R. Trigger, P, A bits, NAI] | 368 |<-----------------------------------------| 369 | | | 370 | | | 371 | | | 372 | | | 373 | BRA [seq.#, Cause, P bit] | 374 |----------------------------------------->| 375 | | | 376 | | | 378 Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff 380 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings 382 The local mobility anchor sends a BRI message to indicate that all 383 bindings which are hosted by the peer mobile access gateway and 384 registered with the local mobility anchor are being revoked by 385 setting the G bit as described in Section 8.1.1. 387 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings 389 The mobile access gateway sends a BRI message with the G bit is set 390 to indicate that all mobility sessions which are registered at the 391 LMA and attached to the MAG are being revoked as in Section 9.2.1. 392 When the LMA receives a BRI message with the G bit is set from a 393 specified MAG, the LMA checks if the MAG is authorized to use global 394 revocations and responds with the appropriate status code by sending 395 a BRA message as in Section 8.2.2. 397 4. Security Model 399 The revocation protocol described here requires the revocation 400 messages to be defined as subtypes of the Mobile IPv6 Generic 401 Signalling Message which is assigned a MH type value 402 [ID-MGSM] that requires IPsec protection. This is needed in order 403 when IPsec is used for securing the mobility signalling between , 404 e.g., the MAG and the LMA, the IPsec SPD will allow all MGSM packets 405 including those which carry binding revocation messages. 407 Additionally, in the case when the LMA receives a BRI which indicates 408 a bulk termination, the LMA MUST verify that the MAG sending the 409 revocation indication message is authorized for Per-Peer Global 410 revocation. 412 5. Binding Revocation Messages 414 This section defines two messages by reserving two subtypes of the 415 Mobile IPv6 Generic Signalling Message that use the MH type which 416 requires IPsec protection as defined in [ID-MGSM]. 418 5.1. Binding Revocation Indication Message 420 The Binding Revocation Indication (BRI) message is used by the 421 revoking mobility node to inform the receiving mobility entity that 422 the IP mobility service of a specific binding or bindings have been 423 revoked. Binding Revocation Indication message is sent as described 424 in Section 7.1, Section 8.1.1, and Section 9.2.1. 426 The Binding Revocation Indication (BRI) message uses the subtype 427 of the MGSM message that use the MH type which requires 428 IPsec protection as in [ID-MGSM]. When this subtype is indicated in 429 the subtype field of the MGSM, the format of the Message Data field 430 in the MGSM message following the subtype field is as in Figure 4 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Sequence # | R. Trigger |P|A|G|Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | | 438 . . 439 . Mobility options . 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Figure 4: Binding Revocation Indication Message 445 Sequence # 447 A 16-bit unsigned integer used by the sending mobility node to 448 match a returned Binding Revocation Acknowledgement with this 449 Binding Revocation Indication. 451 Revocation Trigger 453 8-bit unsigned integer indicting the event which triggered the 454 revoking node to send the BRI message. The following Revocation 455 Trigger values are currently defined: 457 0 Reserved. 458 1 Unspecified. 459 2 Administrative Reason. 460 3 Inter-MAG Handover over same Access Types. 461 4 Inter-MAG Handover over different Access Types. 462 5 Per-Peer Policy. 463 6 Local Policy. 465 Proxy Binding (P) 467 The Proxy Binding (P) bit is set by the sending mobility node to 468 indicate that the revoked binding is a proxy MIPv6 binding. 470 Acknowledge (A) 472 The Acknowledge (A) bit is set by the sending mobility node, e.g. 473 LMA, HA, or MAG, to request a Binding Revocation Acknowledgement 474 be returned upon receipt of the Binding Revocation Indication as 475 in Section 7.1, Section 8.1.1, and Section 9.2.1. 477 Global (G) 479 The Global (G) bit is set by the sending mobility node, LMA or 480 MAG, to request the termination of all Per-Peer mobility Bindings 481 that are served by the sending and receiving mobility entities as 482 in Section 8.1.1 and Section 9.2.1. 484 Reserved 486 These fields are unused. They MUST be initialized to zero by the 487 sender and MUST be ignored by the receiver. 489 Mobility Options 491 Variable-length field of such length that the complete Mobility 492 Header is an integer multiple of 8 octets long. This field 493 contains zero or more TLV-encoded mobility options. This document 494 does not define any new mobility option. The receiver MUST ignore 495 and skip any options which it does not understand. These mobility 496 option(s) are used by the receiving mobility entity to identify 497 the specific binding or bindings that the sending mobility entity 498 requesting to be revoked. 500 The following options are valid in a Binding Revocation Indication: 502 o Home Network Prefix option [ID-PMIP6]. This option is mandatory 503 when the P bit is set. 505 o Mobile Node Identifier Option [RFC4283]. This option is mandatory 506 when the P bit is set. Additionally, If the G bit is set by the 507 mobile access gateway, this option include the MAG identity. 509 o Binding ID mobility option [ID-MCoA]. This option is mandatory if 510 the sending mobility entity request to terminate one binding of a 511 multi care-of addresses bindings for the same mobile node. The 512 sending Mobility entity may include more than one of these 513 mobility options. 515 o IPv4 Home Address option which contains the mobile node home IPv4 516 address [ID-DSMIP6]. 518 If no options are present in this message, 4 octets of padding are 519 necessary and the Header Len field of the MGSM will be set to 1. 521 5.2. Binding Revocation Acknowledgement Message 523 The Binding Revocation Acknowledgement is used to acknowledge receipt 524 of a Binding Revocation Indication described in Section 5.1. This 525 packet is sent as described in Section 8.2.2, Section 9.1.2, and 526 Section 10.2. 528 The Binding Revocation Acknowledgement uses the subtype 529 of the MGSM message that use the MH type which requires IPsec 530 protection as in [ID-MGSM]. When this subtype is indicated in the 531 subtype field of the MGSM, the format of the Message Data field in 532 the MGSM message following the subtype field is as in Figure 5: 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Sequence # | Status |P|G| Reserved | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 . . 541 . Mobility options . 542 . . 543 | | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Figure 5: Binding Revocation Acknowledgement Message 548 Sequence # 550 The sequence number in the Binding Revocation Acknowledgement is 551 copied from the Sequence Number field in the Binding Revocation 552 Indication. It is used by the revoking mobility entity, e.g. HA, 553 LMA, in matching this Binding Revocation Acknowledgement with the 554 outstanding BRI. 556 Status 558 8-bit unsigned integer indicating the result of processing the 559 Binding Revocation Indication message by the receiving mobility 560 entity. The following status values are currently defined. 562 0 success. 563 1 partial success. 564 2 Binding Does NOT Exist. 565 3 Global Revocation NOT Authorized. 566 4 CAN NOT Identify Binding. 568 Proxy Binding (P) 570 The Proxy Binding (P) bit is set if the (P) bit is set in the 571 corresponding Binding Revocation Indication message. 573 Global (G) 575 The Global (G) bit is set if the (G) bit is set in the 576 corresponding BRI message. Section 8.2.2 and Section 9.1.2. 578 Reserved 580 These fields are unused. They MUST be initialized to zero by the 581 sender and MUST be ignored by the receiver. 583 Mobility Options 585 Variable-length field of such length that the complete Mobility 586 Header is an integer multiple of 8 octets long. This field 587 contains zero or more TLV-encoded mobility options. In the case 588 when the Status field is set to success, no mobility option is 589 required. The mobility option(s) is usually used to communicate 590 information of the bindings that failed the revocation procedure. 592 The following options are valid in a Binding Revocation 593 Acknowledgement: 595 o Home Network Prefix option [ID-PMIP6]. This option is mandatory 596 when the P bit is set. 598 o Mobile Node Identifier Option [RFC4283]. This option SHOULD be 599 included if the Home Network Prefix option is included. 601 o Binding ID mobility option [ID-MCoA]. This option MAY be included 602 to indicate the specific Binding ID that the receiving node failed 603 to revoke. 605 If no options are present in this message, 4 octets of padding are 606 necessary and the Header Len field of the MGSM will be set to 1. 608 6. Binding Revocation Process Considerations 610 The following subsections describe the details of the binding 611 revocation generic process by the different mobility entities. 613 6.1. Sending Binding Revocation Messages 615 When sending a Binding Revocation message, the sending mobility node, 616 initiator, follows the rules of constructing a MGSM as in [ID-MGSM] 617 and by setting the subtype field to a value to indicate a 618 BRI message. 620 The mobility entity which initiates the revocation process, 621 initiator, MUST use the underlying IPsec security association as 622 described in [ID-MGSM] to secure the BRI and BRA messages 623 transmission with the responding mobility entity, responder. 625 When a mobility entity initiate the binding revocation process by 626 sending a Binding Revocation Indication, the initiator MUST construct 627 the BRI message as described in Section 5.1. In the BRI message, the 628 initiator MUST set the Sequence Number field to the next sequence 629 number available for Binding Revocation. Since sending Binding 630 Revocation Indication messages is not done on a regular basis, a 16 631 bit sequence number field is large enough to allow the initiator to 632 match the Binding Revocation Acknowledgement to the outstanding 633 Binding Revocation Indication with (A) bit set using the sequence 634 number field only. 636 On the other hand, when the responder acknowledge the BRI message by 637 sending a BRA, the responder follows the rules of constructing a MGSM 638 as in [ID-MGSM] and by setting the subtype field to a value to indicate a BRA message and MUST construct the Binding 640 Revocation Acknowledgement as described in Section 5.2. In this 641 case, the responder MUST set the Sequence Number field by copying the 642 value from the Sequence Number field of the received Binding 643 Revocation Indication. Additionally, it MUST set the status field to 644 a valid value that reflects the processing of the received Binding 645 Revocation Indication. 647 6.2. Receiving Binding Revocation Messages 649 When receiving a Binding Revocation message, the receiving mobility 650 node MUST verify the Mobile IPv6 Generic Signaling Message as in 651 [ID-MGSM]. If the packet is dropped due to the receiving node does 652 not support Binding Revocation Indication as a MGSM with subtype 653 , it MUST follow the processing rules as in [ID-MGSM] and 654 it MUST send a Binding Error message with the Status field set to 2 655 (unrecognized MH Type value). 657 Since some mobility entities, e.g. LMA and MAG, are allowed to 658 receive and possibly send a BRI or a BRA for different cases, IPsec 659 mechanism will prevent any possible man in the middle reflection 660 attack. 662 Upon receiving a packet carrying a Binding Revocation Indication, the 663 receiving mobility entity, responder, validates that the packet was 664 received protected with the underlying IPsec protection with the 665 responding mobility entity as described in [ID-MGSM]. 667 Upon receiving a packet carrying a Binding Revocation 668 Acknowledgement, the receiving mobility entity, initiator, MUST 669 validate that Sequence Number field matches the Sequence Number of an 670 outstanding Binding Revocation Indication that was sent by the 671 initiator. If the Sequence Number does not match any sequence number 672 of any of the outstanding BRI, the receiving node MUST ignore the 673 message but MAY log the event. 675 6.3. Retransmission of Binding Revocation Indication 677 If the sending mobility entity does not receive a Binding Revocation 678 Acknowledgement in response to the outstanding Binding Revocation 679 Indication before the MINDelayBRIs timer expires, the mobility 680 entity, e.g. LMA, may retransmit the same BRI message up to the 681 BRIMaxRetriesNumber as defined in Section 11. If the revoking 682 mobility entity does not receive a BRA message after the maximum 683 number of retransmits have been sent, the revoking mobility entity 684 can clean the mobile node binding cache and all resources associated 685 with this binding. The revoking mobility entity may log the event. 687 7. Home Agent Operation 689 7.1. Sending Binding Revocation Indication 691 When an event requires the home agent to terminate a mobile node 692 mobile IPv6 registration, e.g. for administrative reason, the home 693 agent sends a Binding Revocation Indication message to the mobile 694 node to inform the mobile node that its specified binding has been 695 revoked and it will no longer be able to receive an IP connectivity 696 via its binding with the home agent. 698 To terminate a mobile node registration and its current binding with 699 the home agent, the home agent sends a packet to the mobile node 700 containing a Binding Revocation Indication, with the packet 701 constructed as follows: 703 o The Acknowledge (A) bit MAY be set in the Binding Revocation 704 Indication to request the mobile node to send a Binding Revocation 705 Acknowledgement upon receipt of the BRI. 707 o The Revocation Trigger field MUST be set in the Binding Revocation 708 Indication to indicate to the mobile node the reason for revoking 709 its IP mobility binding with the home agent. The Revocation 710 Trigger may be used by the mobile node to take further steps if 711 necessary. 713 o The packet MUST contain a Home Address destination option, which 714 contains the mobile node's registered home address for the binding 715 being revoked. 717 o The care-of address for the binding MUST be used as the Source 718 Address in the packet's IPv6 header, unless an Alternate Care-of 719 Address mobility option is included in the Binding Revocation 720 Indication. 722 o The packet MAY contain a Home Address option which contains the 723 mobile node's registered IPv4 home address for the binding being 724 revoked. 726 The Acknowledge (A) bit in the Binding Revocation Indication requests 727 the mobile node to return a Binding Revocation Acknowledgement in 728 response to this Binding Revocation Indication. As described in 729 Section 6.3, the home agent SHOULD retransmit this Binding Revocation 730 Indication to the mobile node before terminating its IP connection 731 until it receives a matching Binding Revocation Acknowledgement or 732 the BRIMaxRetransmitNumber has been reached. 734 When the home agent send a Binding Revocation Indication to the 735 mobile node, the home agent sets a flag in the mobile node BCE to 736 indicate that revocation is in progress and starts the MINDelayBRIs 737 timer. The home agent maintain the mobile node BCE in this state 738 until it receives a Binding Revocation Acknowledgement or the 739 BRIMaxRetransmitNumber is reached. 741 When the home agent needs to revoke one or more of a mobile node 742 bindings that were created using Multi Care-of address registration 743 as in [ID-MCoA], the home agent MUST include all the related Binding 744 ID options that identify these bindings. In the case when the home 745 agent needs to revoke all of the mobile node bindings, the home agent 746 MUST use the mobile node home address in the Home Address destination 747 option and MUST NOT include any Binding ID option. 749 The home agent MUST use the IPsec security association as described 750 in [ID-MGSM] to secure the MGSM that carries the BRI and BRA messages 751 transmission with the mobile node. 753 7.2. Receiving Binding Revocation Acknowledgement 755 When the home agent receives a packet carrying a valid Binding 756 Revocation Acknowledgement that was successfully processed as in 757 Section 6.2, the home SHOULD examine the Status field as follows: 759 o If the Status field indicates that the Binding Revocation 760 Indication was processed successfully, the home agent delete the 761 MINDelayBRIs timer and the mobile node bindings and all related 762 resources. 764 o If the Status field indicates any value other than success, the 765 home agent SHOULD examine any mobility options included in the 766 Binding Revocation Acknowledgement. The home agent MAY log the 767 appropriate event to reflect the status of the received BRA. 769 8. Local Mobility Anchor Operation 771 8.1. Binding Revocation Initiator 773 8.1.1. Sending Binding Revocation Indication 775 When an event requires the local mobility agent to terminate a mobile 776 node proxy mobile IPv6 registration, e.g. for administrative reason 777 or inter-MAG handover, the local mobility agent sends a Binding 778 Revocation Indication message to the mobile access gateway which host 779 the mobile node proxy CoA to indicate that the mobile node specified 780 binding should be removed. It also indicate that the local mobility 781 anchor will no longer maintain a tunnel for this mobile node binding 782 which points to the mobile node proxy CoA that is hosted at this 783 mobile access gateway. 785 To terminate a mobile node proxy mobile IPv6 registration and its 786 current PMIPv6 binding with the local mobility agent, the local 787 mobility agent sends a packet to the mobile access gateway containing 788 a Binding Revocation Indication following the procedure in 789 Section 6.1 and the following rules: 791 o The Acknowledge (A) bit MAY be set in the Binding Revocation 792 Indication to request the mobile access gateway to send a Binding 793 Revocation Acknowledgement upon receipt of the BRI. 795 o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation 796 Indication to indicate that the binding being revoked is a proxy 797 Mobile IPv6 binding. 799 o The Revocation Trigger field MUST be set in the Binding Revocation 800 Indication to indicate to the mobile access gateway the reason for 801 removing the specified mobile node proxy mobile IPv6 binding at 802 the local mobility anchor. The Revocation Trigger may be used by 803 the mobile access gateway node to learn the mobile node latest 804 movement. 806 o The Global (G) bit MUST be set and the Revocation Trigger MUST 807 contain a value of Per-Peer Policy in the Binding Revocation 808 Indication to request the mobile access gateway to remove all Per- 809 Peer bindings that are registered with the local mobility anchor 810 and hosted at this mobile access gateway. 812 o Whenever the Global (G) bit is set in the BRI, the Acknowledge (A) 813 bit MUST be set to request the mobile access gateway to send a 814 Binding Revocation Acknowledgement upon receipt of the BRI. 816 o The packet MUST contain the Mobile Node Identifier, MN-ID, option 817 which contains the mobile node's NAI that was used in the Binding 818 Update during the mobile node registration. 820 o The packet MUST contain a Home Network Prefix option, which 821 contains the mobile node's registered Home Network Prefix for the 822 binding being revoked. 824 o The care-of address for the binding MAY be used as the Source 825 Address in the packet's IPv6 header, unless an Alternate Care-of 826 Address mobility option is included in the Binding Revocation 827 Indication. 829 The Acknowledge (A) bit in the Binding Revocation Indication requests 830 the mobile access gateway to return a Binding Revocation 831 Acknowledgement in response to this Binding Revocation Indication. 832 As described in Section 6.3, the local mobility anchor SHOULD 833 retransmit this Binding Revocation Indication to the mobile access 834 gateway before deleting the mobile node IP tunnel to the mobile 835 access gateway until it receives a matching Binding Revocation 836 Acknowledgement or the BRIMaxRetransmitNumber is reached. The local 837 mobility anchor MAY delete the mobile node(s) IP tunnel immediately 838 after sending the Binding Revocation Indication before receiving the 839 BRA message. 841 When the local mobility anchor send a Binding Revocation Indication 842 to the mobile access gateway to remove a specific binding, the local 843 mobility anchor sets a flag in the mobile node proxy BCE to indicate 844 that revocation is in progress and starts the MINDelayBRIs timer. 845 The local mobility anchor SHOULD maintain the mobile node proxy BCE 846 in this state until it receives a Binding Revocation Acknowledgement 847 or the BRIMaxRetransmitNumber is reached. In the case when the local 848 mobility anchor sets the Revocation Trigger field to a value which 849 indicate inter-MAG handover, the local mobility anchor MAY switch the 850 mobile node IP tunnel to the target mobile access gateway before 851 sending a Binding Revocation Indication to the sources mobile access 852 gateway. 854 When the local mobility anchor needs to revoke all mobile nodes proxy 855 BCE that are registered with the local mobility anchor and hosted at 856 the mobile access gateway, the local mobility anchor MUST set the 857 Global (G) bit and the value of the Revocation Trigger field to Per- 858 Peer Policy. In this case, the local mobility anchor MUST NOT 859 include any mobility options in the Binding Revocation Indication. 861 When the local mobility anchor needs to revoke all mobile nodes proxy 862 BCE that belong to a specific realm, e.g. @companyabc.com, and are 863 registered with the local mobility anchor and hosted at the mobile 864 access gateway, the local mobility anchor MUST set the Global (G) bit 865 and the value of the Revocation Trigger field to Local Policy. In 866 this case, the local mobility anchor MUST include a mobility option 867 to identify the impacted bindings, e.g. MN-ID option with a wildcard 868 NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs 869 that need to be removed. 871 When the mobile node is registered with multiple Home Network 872 Prefixes for the same proxy care-of address, the local mobility 873 anchor SHOULD include a Home Network Prefix option for each 874 registered Home Network Prefix in the Binding Revocation Indication. 875 Alternatively, the local mobility anchor MAY include only the mobile 876 node identifier, MN-ID, option in the Binding Revocation Indication 877 to indicate to the mobile access gateway to remove all bindings of 878 the specified mobile node NAI in the MN-ID option. 880 8.1.2. Receiving Binding Revocation Acknowledgement 882 When the local mobility anchor receives a packet carrying a valid 883 Binding Revocation Acknowledgement that was successfully processed as 884 in Section 6.2 and if the mobile node BCE is in the state of 885 Revocation in progress, the local mobility anchor SHOULD examine the 886 Status field before clearing the mobile node related resources as 887 follows: 889 o If the Status field indicates that the Binding Revocation 890 Indication was processed successfully, the local mobility anchor 891 delete the MINDelayBRIs timer and the mobile node proxy bindings 892 and all associated resources. 894 o If the Status field indicates partial success value or MN binding 895 does not exist, the local mobility anchor SHOULD examine mobility 896 options that included in the Binding Revocation Acknowledgement, 897 if any, before deleting the MINDelayBRIs timer and the mobile node 898 associated proxy bindings and all related resources. It is based 899 on the local mobility anchor local policy how to handle the Mobile 900 node BCE that the mobile access gateway indicated it failed the 901 revocation procedure, however, the LMA MAY log the event. 903 8.2. Binding Revocation Responder 905 8.2.1. Receiving Binding Revocation Indication 907 When the local mobility anchor receives a packet carrying a Binding 908 Revocation Indication that was successfully processed as in 909 Section 6.2, the local mobility anchor SHOULD in addition process the 910 message as follows: 912 o Binding Revocation Indication is formatted as in Section 5.1 and 913 if the (P) bit is set, the local mobility anchor must validate 914 that all the impacted bindings MUST have the proxy binding flag 915 set. 917 o If the Global (G) bit is set, the Binding Revocation Indication 918 SHOULD contain the mobile access gateway ID in the MN-ID option. 919 The local mobility anchor MUST verify that the identified mobile 920 access gateway as per the value in the MN-ID option is authorized 921 to use the Per-Peer Global bindings revocation. The mechanism the 922 local mobility anchor use to verify the mobile access gateway 923 authorization is out of scope of this document. When the (P) bit 924 is set, this Binding Revocation Indication impact only the mobile 925 nodes bindings that have the Proxy Mobile IP flag set. 927 o The local mobility anchor identify all impacted mobile nodes 928 bindings and if the Acknowledgement (A) bit is set, the local 929 mobility anchor MUST send a Binding Revocation Acknowledgement 930 following Section 8.2.2 using the appropriate status code. 932 o If the Global (G) bit is not set, the local mobility anchor MUST 933 use the included mobility options to identify the impacted mobile 934 node binding as follows: 936 1. If only the mobile node identifier, MN-ID, option is included, 937 the local mobility anchor MUST revoke all bindings for this 938 mobile node which have a proxy CoA that is hosted at the 939 mobile access gateway that sent the BRI. 941 2. If the mobile node identifier, MN-ID, and the Home Network 942 Prefix option are included, the local mobility anchor MUST 943 only remove the specified proxy binding. 945 3. If the mobile node identifier, MN-ID, option and more than one 946 Home Network Prefix options are included, the local mobility 947 anchor need to remove the mobile node bindings which are 948 referenced in these multiple Home Network Prefixes for the 949 specified mobile node NAI. 951 The Revocation Trigger field value in the received Binding Revocation 952 Indication could be used by the local mobility anchor to log an event 953 or update some local parameters which tracks the state of the peer 954 mobile access gateway. 956 8.2.2. Sending Binding Revocation Acknowledgement 958 When the local mobility anchor receive a valid Binding Revocation 959 Indication with the (A) bit is set and after processing the BRI 960 message, the local mobility anchor sends a packet to the mobile 961 access gateway containing a Binding Revocation Acknowledgement 962 following the process in Section 6.1 and the following: 964 o If the (P) bit was set in the received Binding Revocation 965 Indication, the local mobility anchor MUST set the (P) bit in the 966 Binding Revocation Acknowledgement. 968 o If the Global (G) bit was set in the received BRI, the local 969 mobility anchor MUST set the (G) bit in the Binding Revocation 970 Acknowledgement. 972 o The local mobility anchor MUST set the status field to a valid 973 code that reflects the processing of the received Binding 974 Revocation Indication. If the mobile access gateway is not 975 authorized to use the Per-Peer Global revocation feature, the LMA 976 MUST set the status field to (Global Revocation NOT Authorized). 978 o The local mobility MAY set the status field to partial success and 979 in this case it MAY include the mobile node identifier or the Home 980 Network Prefix option to identify the bindings that failed 981 revocation. 983 o The destination IP address of the IPv6 packet of the Binding 984 Revocation Acknowledgement is set to the source IP address of the 985 received Binding Revocation Indication. 987 9. Mobile Access Gateway Operation 989 9.1. Binding Revocation Responder 991 9.1.1. Receiving Binding Revocation Indication 993 Upon receiving a packet carrying a Binding Revocation Indication, the 994 mobile access gateway MUST validate the packet according to 995 Section 6.2 and the following: 997 o Binding Revocation Indication MUST be formatted as in Section 5.1 998 and if the (P) bit is set, the mobile access gateway must validate 999 that the impacted binding have the proxy binding flag set. 1001 o If the Acknowledgement (A) bit in the received BRI is set, the 1002 mobile access gateway MUST send a Binding Revocation 1003 Acknowledgement following Section 9.1.2 using the appropriate 1004 status value. 1006 o If the Global (G) bit is set and the Revocation Trigger field is 1007 set to Per-Peer policy, the mobile access gateway identify all 1008 bindings that are registered at the local mobility anchor and 1009 hosted at the mobile access gateway. This Binding Revocation 1010 Indication does not include any other mobility options. However, 1011 if the (P) bit is set, this Binding Revocation Indication MUST 1012 only impact mobile nodes bindings that have the Proxy Mobile IP 1013 flag set. 1015 o If the Global (G) bit is set and the Revocation Trigger field is 1016 set to Local policy, the mobile access gateway MUST identify all 1017 bindings that are registered at the local mobility anchor and 1018 hosted at the mobile access gateway using the mobility option 1019 included in the Binding Revocation Indication. This Binding 1020 Revocation SHOULD include at least the MN-ID option, e.g. with a 1021 wild card NAI. 1023 o If the Global (G) bit is set and the Revocation Trigger field is 1024 set to Local policy, and no mobility options are included in the 1025 Binding Revocation Indication message, the mobile access gateway 1026 MUST treat this as an error scenario. In this case, the mobile 1027 access gateway SHOULD send a Binding Revocation Acknowledgement 1028 message with status "CAN NOT Identify Binding". 1030 The Revocation Trigger field value in the received Binding Revocation 1031 Indication could be used by the mobile access gateway to define what 1032 actions the mobile access gateway could do to inform the mobile node 1033 that its IP connectivity to the current Home Network Prefix has been 1034 terminated. e.g. if the Revocation Trigger field is set to 1035 administrative value, the mobile access gateway may send a RA message 1036 after setting the Home Network Prefix lifetime to zero. 1038 If the Revocation Trigger field value in the received Binding 1039 Revocation Indication message indicate an inter-MAG handover and the 1040 (A) bit is set, the mobile access gateway MAY validate that the 1041 mobile node is no longer attached to the mobile access gateway before 1042 sending a Binding Revocation Acknowledgement message to the local 1043 mobility anchor. 1045 9.1.2. Sending Binding Revocation Acknowledgement 1047 When the mobile access gateway receive a valid Binding Revocation 1048 Indication with the (A) bit is set and after processing the BRI 1049 message, the mobile access gateway sends a packet to the local 1050 mobility anchor containing a Binding Revocation Acknowledgement 1051 according to the procedure in Section 6.1 and the following: 1053 o The mobile access gateway MUST set the (P) bit in the Binding 1054 Revocation Acknowledgement if it is set in the received BRI. 1056 o If the Global (G) bit was set in the received BRI, the mobile 1057 access gateway MUST set the (G) bit in the Binding Revocation 1058 Acknowledgement. 1060 o The mobile access gateway MUST set the status field to a valid 1061 code that reflects the processing of the received Binding 1062 Revocation Indication. 1064 o The mobile access gateway MAY set the status field to partial 1065 success and in this case it MAY include the mobile node 1066 identifier, MN-ID, or the Home Network Prefix option to identify 1067 the binding(s) that failed to be removed as part of the revocation 1068 procedure. 1070 o The destination IP address of the IPv6 packet of the Binding 1071 Revocation Acknowledgement is set to the source IP address of the 1072 received Binding Revocation Indication. 1074 9.2. Binding Revocation Initiator 1076 9.2.1. Sending Binding Revocation Indication 1078 The mobile access gateway send a Binding Revocation Indication when 1079 it needs to use global revocation, i.e. when the G bit is set. In 1080 this case when an event occurs which requires the mobile access 1081 gateway to inform the local mobility anchor to terminate all mobile 1082 nodes bindings that are registered at the local mobility anchor and 1083 the mobile access gateway, the mobile access gateway send a Binding 1084 Revocation Indication message following Section 6.1 and the 1085 following: 1087 o The Acknowledge (A) bit MUST be set in the Binding Revocation 1088 Indication to request the local mobility anchor to send a Binding 1089 Revocation Acknowledgement upon receipt of the BRI. 1091 o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation 1092 Indication to indicate that bindings that being revoked is a proxy 1093 Mobile IPv6 binding. 1095 o The Global (G) bit MUST be set and the Revocation Trigger MUST 1096 contain a value of Per-Peer Policy in the Binding Revocation 1097 Indication to request the local mobility anchor to remove all Per- 1098 Peer bindings that are registered with the local mobility anchor 1099 and hosted at this mobile access gateway. In this case, the 1100 mobile node identifier, MN-ID, option MUST be included in the BRI 1101 and MUST contain the mobile access gateway identity 1103 o The mobile access gateway address MAY be used as the Source 1104 Address in the packet's IPv6 header. 1106 The Acknowledge (A) bit in the Binding Revocation Indication requests 1107 the local mobility anchor to return a Binding Revocation 1108 Acknowledgement in response to this Binding Revocation Indication. 1109 As described in Section 6.3, the mobile access gateway SHOULD 1110 retransmit this Binding Revocation Indication to the local mobility 1111 anchor until it receives a matching Binding Revocation 1112 Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile 1113 access gateway MAY delete the mobile nodes IP tunnels immediately 1114 after sending the Binding Revocation Indication before receiving a 1115 BRA message from the LMA. 1117 9.2.2. Receiving Binding Revocation Acknowledgement 1119 When the mobile access gateway receive a packet carrying a valid 1120 Binding Revocation Acknowledgement that was successfully processed 1121 according to Section 6.2, the mobile access gateway MUST validate the 1122 BRA as per the followings: 1124 o When the mobile access gateway receive a packet carrying a valid 1125 Binding Revocation Acknowledgement and the Global (G) and Proxy 1126 MIPv6 (P) bits are set and the mobile nodes BCEs are in the state 1127 of Revocation in Progress, the mobile access gateway SHOULD 1128 examine the Status field as follows: 1130 o If the Status field indicates that the Binding Revocation 1131 Indication was processed successfully, the mobile access gateway 1132 delete the MINDelayBRIs timer and the mobile nodes proxy bindings 1133 and all associated resources. 1135 o If the Status field indicates (Global Revocation NOT Authorized), 1136 the mobile access gateway is not authorized to participate in a 1137 Per-Peer Global Revocation. The mobile access gateway SHOULD NOT 1138 retry sending a Binding Revocation Indication with the Global (G) 1139 bit is set to the same local mobility agent. The mobile access 1140 gateway should raise an alarm or log an event to indicate this 1141 rejection. 1143 10. Mobile Node Operation 1145 10.1. Receiving Binding Revocation Indication 1147 Upon receiving a packet carrying a Binding Revocation Indication, the 1148 mobile node MUST validate the packet according to Section 6.2 and the 1149 following tests: 1151 o The mobile node MUST verify that the IP address in the Home 1152 Address option is its Home Address. 1154 o If the Acknowledgement (A) bit is set in the Binding Revocation 1155 Indication and the MN has the BCE in registered state, the mobile 1156 node MUST send a Binding Revocation Acknowledgement. However, in 1157 all other cases when the (A) bit is set in the BRI, the mobile 1158 node SHOULD send a Binding Revocation Acknowledgement. In all 1159 cases, the mobile node MUST follow Section 10.2 when send a BRA 1160 using the appropriate status code. 1162 o The mobile node MUST verify that the (P) bit in the Binding 1163 Revocation Indication is NOT set. If the (P) bit is set, the 1164 mobile node MUST silently discard the Binding Revocation 1165 Indication. 1167 o If the Revocation Trigger field value is Administrative, the 1168 mobile node MUST not try to re-register with the home agent before 1169 contacting its home operator. 1171 o If the mobile node has registered multiple care-of addresses with 1172 its home agent, the mobile node MUST verify which binding is being 1173 revoked by examining the content of the BRI message. If the 1174 mobile node received a Binding Revocation Indication with a single 1175 or more than one BID options and its home address is in the Home 1176 Address option, the mobile node MUST consider its bindings 1177 identified in the Binding ID options are being revoked. 1179 o If the mobile node has multi Care-of Addresses bindings with its 1180 home agent and received a Binding Revocation Indication, with only 1181 its home address in the Home Address option, the mobile node MUST 1182 consider all of its registered care-of addresses bindings with 1183 this home address have been revoked. 1185 The Revocation Trigger field value in the received Binding Revocation 1186 Indication could be used by the mobile node to define what action the 1187 mobile node could do to be able to register again and receive its IP 1188 mobility service, e.g. contacting its home operator. 1190 10.2. Sending Binding Revocation Acknowledgement 1192 When the mobile node receive a valid Binding Revocation Indication 1193 with the (A) bit is set from its home agent and while having this BCE 1194 in registered state, the mobile node MUST send a packet to its home 1195 agent containing a Binding Revocation Acknowledgement according to 1196 the procedure in Section 6.1 and the following: 1198 o The mobile node MUST set the status field to successful to reflect 1199 that it has received the Binding Revocation Indication and 1200 acknowledge that its IP connectivity with its home agent has been 1201 revoked. 1203 o The destination IP address of the IPv6 packet of the Binding 1204 Revocation Acknowledgement is set to the source IP address of the 1205 received Binding Revocation Indication. 1207 o If the mobile node receive a Binding Revocation Indication from a 1208 home agent which the mobile node does not have a registered 1209 binding with, the mobile node SHOULD silently discard the BRI 1210 message. The mobile node should continue to use its assigned HoA 1211 to access its IP mobility service. 1213 11. Protocol Configuration Variables 1215 Any mobility entity which is allowed to invoke the binding revocation 1216 procedure by sending a Binding Revocation Indication message SHOULD 1217 allow the following variables to be configured. 1219 BRI Maximum Number of Retries (BRIMaxRetriesNumber) 1221 This variable specifies the maximum Number of times a mobility 1222 entity can retransmit a Binding Revocation Indication message 1223 before receiving a Binding Revocation Acknowledgement message. 1224 The default value for this parameter is 1. 1226 Minimum Delay Between BRI messages (MINDelayBRIs) 1228 This variable specifies the delay time in seconds before the 1229 revoking mobility entity retransmits a BRI message. The default 1230 is 1 second but not less than 0.5 seconds. 1232 12. IANA Considerations 1234 This document defines two new messages BRI and BRA, as described in 1235 Section 5.1 and Section 5.2 by using two subtypes of the Mobile IPv6 1236 Generic Signalling Message which uses a MH type as in 1237 [ID-MGSM] which requires the use of IPsec, The new subtype values 1238 needs to be assigned from the same 1239 numbering space as allocated for the other MGSM subtypes. 1241 13. Security Considerations 1243 The protocol described here uses the same security association 1244 between the MN and the HA or the MAG and the LMA that has been used 1245 to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the 1246 session was established. If IPsec is used, The SPD of this IPsec SA 1247 MUST allow the MH type for the MGSM. 1249 However, in the case when the MAG sends a BRI message with the G bit 1250 is set, the LMA MUST verify that the MAG is authorized to use Per- 1251 Peer Global Revocation. 1253 14. Acknowledgements 1255 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1256 Cazavet and Domagoj Premec for their review and comments of this 1257 draft and all colleagues who have supported the advancement of this 1258 draft effort. 1260 15. References 1262 15.1. Normative References 1264 [ID-DSMIP6] 1265 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1266 Routers", draft-ietf-mext-nemo-v4traversal-04 (work in 1267 progress), June 2008. 1269 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1270 "Multiple Care-of Addresses Registration", 1271 draft-ietf-monami6-multiplecoa-08 (work in progress), 1272 May 2008. 1274 [ID-MGSM] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic 1275 Signaling Message", 1276 draft-haley-mext-generic-signaling-message-00 (work in 1277 progress), July 2008. 1279 [ID-PMIP6] 1280 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1281 and B. Patil, "Proxy Mobile IPv6", 1282 draft-ietf-netlmm-proxymip6-18 (work in progress), 1283 May 2008. 1285 [ID-PMIP6-IPv4] 1286 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1287 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 1288 (work in progress), May 2008. 1290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1291 Requirement Levels", BCP 14, RFC 2119, March 1997. 1293 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1294 in IPv6", RFC 3775, June 2004. 1296 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1297 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1298 (MIPv6)", RFC 4283, November 2005. 1300 15.2. Informative References 1302 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1303 August 2002. 1305 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1306 Mobile IPv4", RFC 3543, August 2003. 1308 Authors' Addresses 1310 Ahmad Muhanna 1311 Nortel 1312 2221 Lakeside Blvd. 1313 Richardson, TX 75082 1314 USA 1316 Email: amuhanna@nortel.com 1318 Mohamed Khalil 1319 Nortel 1320 2221 Lakeside Blvd. 1321 Richardson, TX 75082 1322 USA 1324 Email: mkhalil@nortel.com 1326 Sri Gundavelli 1327 Cisco Systems 1328 170 West Tasman Drive 1329 San Jose, CA 95134 1330 USA 1332 Email: sgundave@cisco.com 1334 Kuntal Chowdhury 1335 Starent Networks 1336 30 International Place 1337 Tewksbury, MA 01876 1338 USA 1340 Email: kchowdhury@starentnetworks.com 1341 Parviz Yegani 1342 Cisco Systems 1343 170 West Tasman Drive 1344 San Jose, CA 95134 1345 USA 1347 Email: pyegani@cisco.com 1349 Full Copyright Statement 1351 Copyright (C) The IETF Trust (2008). 1353 This document is subject to the rights, licenses and restrictions 1354 contained in BCP 78, and except as set forth therein, the authors 1355 retain all their rights. 1357 This document and the information contained herein are provided on an 1358 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1359 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1360 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1361 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1362 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1363 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1365 Intellectual Property 1367 The IETF takes no position regarding the validity or scope of any 1368 Intellectual Property Rights or other rights that might be claimed to 1369 pertain to the implementation or use of the technology described in 1370 this document or the extent to which any license under such rights 1371 might or might not be available; nor does it represent that it has 1372 made any independent effort to identify any such rights. Information 1373 on the procedures with respect to rights in RFC documents can be 1374 found in BCP 78 and BCP 79. 1376 Copies of IPR disclosures made to the IETF Secretariat and any 1377 assurances of licenses to be made available, or the result of an 1378 attempt made to obtain a general license or permission for the use of 1379 such proprietary rights by implementers or users of this 1380 specification can be obtained from the IETF on-line IPR repository at 1381 http://www.ietf.org/ipr. 1383 The IETF invites any interested party to bring to its attention any 1384 copyrights, patents or patent applications, or other proprietary 1385 rights that may cover technology that may be required to implement 1386 this standard. Please address the information to the IETF at 1387 ietf-ipr@ietf.org. 1389 Acknowledgment 1391 Funding for the RFC Editor function is provided by the IETF 1392 Administrative Support Activity (IASA).