idnits 2.17.1 draft-ietf-mext-binding-revocation-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to 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 (May 15, 2009) is 5453 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-10 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-12 == Outdated reference: A later version (-10) exists of draft-ietf-mext-nemo-v4traversal-09 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Muhanna 3 Internet-Draft M. Khalil 4 Intended status: Standards Track Nortel 5 Expires: November 16, 2009 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Starent Networks 9 P. Yegani 10 Juniper Networks 11 May 15, 2009 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-06.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 November 16, 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 in effect on the date of 46 publication of this document (http://trustee.ietf.org/license-info). 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. 50 Abstract 52 This document defines a binding revocation mechanism to terminate a 53 mobile node's mobility session and the associated resources. These 54 semantics are generic enough and can be used by mobility entities in 55 the case of Mobile IPv6 and its extensions. This mechanism allows 56 the mobility entity which initiates the revocation procedure to 57 request its corresponding one to terminate either one, multiple or 58 all specified binding cache entries. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 64 2.1. Conventions used in this document . . . . . . . . . . . . 4 65 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 67 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 68 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6 69 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 70 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 71 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 72 Revocation . . . . . . . . . . . . . . . . . . . . . . 9 73 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10 74 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Binding Revocation Messages over IPv4 Transport Network . . . 11 76 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11 77 6.1. Binding Revocation Indication Message . . . . . . . . . . 12 78 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 16 79 7. Binding Revocation Process Operation . . . . . . . . . . . . . 18 80 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 18 81 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 19 82 7.3. Retransmission of Binding Revocation Indication . . . . . 20 83 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 20 84 8.1. Sending Binding Revocation Indication . . . . . . . . . . 20 85 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 22 86 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 22 87 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 22 88 9.1.1. Sending Binding Revocation Indication . . . . . . . . 22 89 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 25 90 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 25 91 9.2.1. Receiving Binding Revocation Indication . . . . . . . 26 92 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 27 93 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 28 94 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 28 95 10.1.1. Receiving Binding Revocation Indication . . . . . . . 28 96 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 30 98 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 30 99 10.2.1. Sending Binding Revocation Indication . . . . . . . . 30 100 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 31 101 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 32 102 11.1. Receiving Binding Revocation Indication . . . . . . . . . 32 103 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 33 104 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 34 105 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 106 14. Security Considerations . . . . . . . . . . . . . . . . . . . 36 107 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 108 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 110 16.2. Informative References . . . . . . . . . . . . . . . . . . 37 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 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 (LMA), involved in providing IP mobility 132 services to a mobile node, to notify the mobile access gateway (MAG) 133 of the termination of a mobile node binding registration. In another 134 example, a mobile access gateway can use this mechanism to notify its 135 local mobility anchor peer with a bulk termination of all or a subset 136 of proxy mobile IPv6 (PMIPv6) bindings that are registered with the 137 local mobility anchor and currently being served by the mobile access 138 gateway. 140 2. Conventions & Terminology 142 2.1. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2.2. Terminology 150 All the general mobility related terminology and abbreviations are to 151 be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile 152 IPv6 [RFC5213] specifications. 154 3. Binding Revocation Protocol and Use Cases Overview 156 This specification specifies a generic binding revocation mechanism 157 where a mobility node can communicate to the mobile node or another 158 mobility node the identity of the the mobile node registration 159 binding that is being terminated. In the case when this mechanism is 160 used for bulk termination or multiple bindings, the identities of 161 these bindings are communicated to the mobile node or mobility node 162 using the same generic mechanism. The following subsections describe 163 the protocol overview and applicable use cases. 165 3.1. Binding Revocation Protocol 167 In the case of Mobile IPv6, if the home network decides to terminate 168 the service of the mobile node, the home agent sends a Binding 169 Revocation Indication (BRI) message to the mobile node. The home 170 agent includes the home address (HoA) of the mobile node in the Type 171 2 routing header as specified in [RFC3775] to indicate the impacted 172 mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) 173 [ID-DSMIP6], the home agent may include the IPv4 Home Address option 174 with the mobile node assigned home IPv4 address. Additionally, if 175 the mobile node registered multiple care-of addresses [ID-MCoA], the 176 home agent includes the Binding Identifier (BID) option(s) in the 177 Binding Revocation Indication message to identify which binding is 178 being revoked. When the mobile node receives a Binding Revocation 179 Indication message with its HoA included in the Type 2 routing header 180 and the Acknowledge (A) bit is set, the mobile node responds by 181 sending a Binding Revocation Acknowledgement (BRA) message. 183 Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation 184 procedure can be initiated by the local mobility anchor by sending a 185 Binding Revocation Indication message to communicate the termination 186 of a mobile node registration binding to the mobile access gateway. 187 In this case, the local mobility anchor includes the mobile node Home 188 Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option 189 [RFC4283] to indicate to the mobility access gateway the identity of 190 the PMIPv6 binding that needs to be terminated. When the mobile 191 access gateway receives the Binding Revocation Indication message 192 with the (A) bit set, the mobile access gateway responds to the local 193 mobility anchor by sending a Binding Revocation Acknowledgement 194 message. 196 On the other hand, the mobile access gateway usually sends a de- 197 registration message by sending a Proxy Binding Update with a 198 lifetime of zero to indicate to the local mobility anchor of the 199 termination of the PMIPv6 mobile node binding registration. In this 200 case, the mobile access gateway includes the MN-HNP option, the MN-ID 201 option and all other required mobility options as per [RFC5213] in 202 order for the local mobility anchor to identify the mobile node 203 PMIPv6 binding. Additionally, in the case when the mobile access 204 gateway communicates a bulk termination of PMIPv6 mobility sessions, 205 the mobile access gateway sends a Binding Revocation Indication 206 message with the (G) and (A) bits set and includes the mobile access 207 gateway identity in the MN-ID option. When the local mobility anchor 208 receives such Binding Revocation Indication message, it ensures that 209 the mobile access gateway is authorized to send such bulk termination 210 message and then processes the Binding Revocation Indication message 211 accordingly. If the local mobility anchor processes the Binding 212 Revocation Indication message successfully, the local mobility anchor 213 responds to the mobile access gateway by sending Binding Revocation 214 Acknowledgement message. 216 In any of the above cases, the initiator of the binding revocation 217 procedure, e.g., home agent, local mobility anchor, mobile access 218 gateway, uses the Revocation Trigger field in the Binding Revocation 219 Indication message to indicate to the receiving node the reason for 220 initiating the revocation procedure. 222 3.2. MIPv6 and DSMIP6 Use Case 224 Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 225 session(s) when the home agent needs to inform the mobile node that 226 its binding registration has been revoked, e.g. for an administrative 227 reason. This mechanism enables the user to react to the revocation, 228 e.g., reinstate its interrupted Mobile IPv6 services. 230 In this case, the home agent sends a Binding Revocation Indication 231 message to indicate to the mobile node that its current mobile IPv6 232 (MIPv6) binding has been revoked and it no longer able to receive IP 233 mobility service. The home agent includes the HoA in Type 2 routing 234 header as used in [RFC3775] and sets the Revocation Trigger field to 235 a proper value, e.g., Administrative Reason. In the case of DSMIPv6 236 session, the home agent may additionally include the mobile node 237 assigned IPv4 Home Address in the IPv4 Home Address option. When the 238 mobile node receives the Binding Revocation Indication message, it 239 sends a Binding Revocation Acknowledgement message as described in 240 Section 11.2 to the home agent. Figure 1 illustrates the message 241 sequencing when home agent revokes a mobile node binding 242 registration. 244 MN HA 245 | | 246 | HoA in Type 2 Hdr | 247 |<<<------------... + ...-----------------| 248 | BRI [seq.#, A bit, Revocation Trigger] | 249 | | 250 | | 251 | BRA (HoA in Dest. Option)[seq.#, Status] | 252 |---------------------------------------->>>| 253 | | 254 | | 256 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 258 3.3. Multi-Care of Addresses (Monami6) Use Case 260 In the case of multiple care-of addresses registration [ID-MCoA], the 261 home agent maintains different binding for each pair of care-of 262 address and home address. These bindings are also indexed and 263 identified during the mobile node registration using a BID mobility 264 option. The HA may revoke one or multiple bindings for the same 265 mobile node home address. 267 If the home agent revokes a single binding for a mobile node with 268 multiple care-of addresses registration, the home agent sends a 269 Binding Revocation Indication message to the mobile node with the 270 corresponding BID option included. If more than one of the mobile 271 node registered care-of addresses need to be revoked, the home agent 272 includes all the corresponding BID options in the same Binding 273 Revocation Indication message. Figure 2 illustrates the message flow 274 when the home agent revokes two registered Care-of addresses for the 275 same mobile node in a single Binding Revocation Indication message. 277 HA Binding Cache 278 ================ 279 MN-BID1 [CoA1+HoA] 280 MN HA MN-BID2 [CoA2+HoA] 281 | | MN-BID3 [CoA3+HoA] 282 | | MN-BID4 [CoA4+HoA] 283 | HoA in Type 2 Hdr | 284 |<<<<-------------- + ---------------------| 285 | BRI [seq.#, A bit, R. Trigger, BID1, BID4] | 286 | | 287 | | 288 | BRA (HoA in Dest. Option) [seq.#, Status] | 289 |---------------------------------------->>>>| 290 | | 291 | | 293 Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings 295 Additionally, the home agent may revoke all of the mobile node 296 registered bindings, by sending a BRI message without including any 297 BID options while the HoA is included in the Type 2 routing header. 298 Figure 1 illustrates the message flow when the home agent revokes all 299 registered Care-of addresses bindings for a mobile node in a single 300 Binding Revocation Indication message. 302 3.4. Proxy MIPv6 Use Case 304 Since the mobile node does not participate in the mobility mechanism 305 in the case of PMIPv6, there are many scenarios where Binding 306 Revocation mechanism is needed to clean resources and make sure that 307 the mobility entities, i.e., mobile access gateway and local mobility 308 anchor, are always synchronized with respect to the status of the 309 existing PMIPv6 bindings. The binding revocation mechanism is 310 generic enough that can be used for all Proxy Mobile IPv6 scenarios 311 that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. 313 When the mobile access gateway receives a Binding Revocation 314 Indication message as in Section 10.1.1, the mobile access gateway 315 sends a Binding Revocation Acknowledgement message to the local 316 mobility anchor following the rules described in Section 10.1.2. 317 Similarly, if the local mobility anchor receives a Binding Revocation 318 Indication message with the (A) bit is set, the local mobility anchor 319 responds to the mobile access gateway by sending a Binding Revocation 320 Acknowledgement message. 322 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation 324 The local mobility anchor may send a Binding Revocation Indication 325 message to the mobile access gateway, hosting a specific PMIPv6 326 binding, with the appropriate value in the revocation trigger field 327 to indicate that the mobile node binding has been terminated and the 328 mobile access gateway can clean up the applicable resources. When 329 the mobile access gateway receives a Binding Revocation Indication 330 message, the mobile access gateway identifies the respected binding 331 and if the (A) bit was set in the received Binding Revocation 332 Indication message, it sends a Binding Revocation Acknowledgement 333 message to the local mobility anchor. In this case, the mobile 334 access gateway could send a Router Advertisement message to the 335 mobile node with the home network prefix valid lifetime set to zero. 337 As an example, Figure 3, illustrates the message sequence for 338 revoking a mobile node binding at the source mobile access gateway 339 during the mobile node inter-MAG handover. During the inter-MAG 340 handover, the mobile node moves from the source MAG to the target 341 MAG. The target MAG sends a Proxy Binding Update with the new care- 342 of-address to the local mobility anchor to update the mobile node's 343 point of attachment. Since the mobile node binding at the local 344 mobility anchor points to the source MAG and upon receiving the Proxy 345 Binding Update from the target MAG, the local mobility anchor updates 346 the MN BCE and send a Proxy Binding Acknowledgement to the target 347 MAG. The local mobility anchor can send a Binding Revocation 348 Indication message with the appropriate revocation trigger value, 349 e.g. inter-MAG handover - different Access Types, to the source MAG 350 in order to clean up the applicable resources reserved for the 351 specified mobile node binding. The mobile access gateway 352 acknowledges the Binding Revocation Indication message by sending a 353 Binding Revocation Acknowledgement message to indicate the success or 354 failure of the termination of the mobile node's binding. 356 The process identified above can also be used by the local mobility 357 anchor in scenarios other than the inter-MAG handover with the proper 358 revocation trigger value to indicate to the peer mobile access 359 gateway that a specific PMIPv6 binding or bindings have been revoked. 361 oldMAG newMAG LMA 362 | | | 363 | | PBU | 364 | |--------------------------->| 365 | | PBU triggers 366 | | BRI Msg to oldMAG 367 | | | 368 | | PBA | 369 | |<---------------------------| 370 | | | 371 | | | 372 | BRI [seq.#, R. Trigger, P, A bits, NAI] | 373 |<-----------------------------------------| 374 | | | 375 | | | 376 | | | 377 | | | 378 | BRA [seq.#, Status, P bit] | 379 |----------------------------------------->| 380 | | | 381 | | | 383 Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover 385 In addition, the local mobility anchor can send a Binding Revocation 386 Indication message to indicate that all bindings which are hosted by 387 the peer mobile access gateway and registered with the local mobility 388 anchor are being revoked by setting the (G) bit as described in 389 Section 9.1.1. 391 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 393 The mobile access gateway sends a BRI message with the (G) bit is set 394 to indicate that all mobility bindings which are registered at the 395 local mobility anchor and attached to the mobile access gateway are 396 being revoked as in Section 10.2.1. When the local mobility anchor 397 receives a Binding Revocation Indication message with the (G) bit is 398 set from a specified mobile access gateway, the local mobility anchor 399 first checks if the mobile access gateway is authorized to use global 400 revocations and then responds with the appropriate status code by 401 sending a Binding Revocation Acknowledgement message as in 402 Section 9.2.2. 404 4. Security Model 406 The binding revocation protocol described here uses the same security 407 association between the mobile node and the home agent or the mobile 408 access gateway and the local mobility anchor that has been used to 409 exchange the corresponding MIPv6 or PMIPv6 Binding Update and Binding 410 Acknowledgement when the mobile node binding was created. If IPsec 411 is used, the traffic selectors associated with the SPD entry 412 protecting the Binding Update and Binding Acknowledgement MUST be 413 extended to include Binding Revocation Signaling MH type . 414 Extending the traffic selectors of the SPD entry in order to reuse 415 the SA protecting Binding Update and Binding Acknowledgement (instead 416 of creating new ones) ensures that those SA will be up and running 417 when the revoking entity needs to send a binding revocation signaling 418 message. 420 Additionally, in the case when the local mobility anchor receives a 421 Binding Revocation Indication which indicates a bulk termination 422 where the (G) bit is set and the Revocation Trigger field is set to 423 "Per-Peer Policy", the local mobility anchor MUST verify that the 424 mobile access gateway sending the binding revocation indication 425 message is authorized to invoke global revocation. 427 5. Binding Revocation Messages over IPv4 Transport Network 429 In some deployments, the network between the mobile access gateway 430 and the local mobility anchor may only support IPv4 transport. In 431 this case, the Binding Revocation messages (BRI and BRA) are tunneled 432 over IPv4. If the Proxy Binding Update and Proxy Binding 433 Acknowledgment messages are sent using UDP encapsulation to traverse 434 NATs, then the Binding Revocation messages are sent using the same 435 UDP encapsulation. The same UDP port that was used for exchanging 436 the Proxy Binding Update and Proxy Binding Acknowledgement messages 437 will also be used when transporting Binding Revocation messages over 438 IPv4 using UDP encapsulation. In other words, the destination UDP 439 port of the Binding Revocation Indication message MUST be set to the 440 source UDP port of the latest successfully processed Proxy Binding 441 Update message which is already saved in the mobile node BCE. For 442 more details on tunneling Proxy Mobile IPv6 signaling messages over 443 IPv4, see [ID-PMIP6-IPv4]. 445 6. Binding Revocation Message 447 This section defines the Binding Revocation Message format using a MH 448 Type as illustrated in Figure 4. The value in the Binding 449 Revocation Type field defines whether the Binding Revocation message 450 is a Binding Revocation Indication or Binding Revocation 451 Acknowledgement. If the Binding Revocation type field is set to 1, 452 the Binding Revocation Message is a Binding Revocation Indication as 453 in Section 6.1. However, if the value is 2, it is a Binding 454 Revocation Acknowledgement message as in Section 6.2. 456 0 1 2 3 457 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 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Payload Proto | Header Len | MH Type | Reserved | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Checksum | B.R. Type | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 463 | | 464 . Binding Revocation Message Data . 465 | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Figure 4: Binding Revocation Message 470 Binding Revocation Type 472 8-bit unsigned integer. It defines the type of Binding Revocation 473 Message. It can be assigned one of the following values: 475 0 Reserved 476 1 Binding Revocation Indication Message 477 2 Binding Revocation Acknowledgement Message 478 All other values are reserved 480 Binding Revocation Message Data 482 The Binding Revocation Message Data follows the Binding Revocation 483 Message format that is defined in this document for the specified 484 value in the Binding Revocation Type field. In this 485 specification, it is either a Binding Revocation Indication as in 486 Section 6.1 or Binding Revocation Acknowledgement as in 487 Section 6.2. 489 6.1. Binding Revocation Indication Message 491 The Binding Revocation Indication (BRI) message is a Binding 492 Revocation Message which has a MH type and a Binding 493 Revocation Type value of 1. It is used by the revoking mobility node 494 to inform the receiving mobility entity of the identity of a specific 495 binding or bindings which IP mobility service have been revoked. 496 Binding Revocation Indication message is sent as described in 497 Section 8.1, Section 9.1.1, and Section 10.2.1. 499 When the value 1 is indicated in the B. R. type field of the Binding 500 Revocation Message, the format of the Binding Revocation Message Data 501 follows the Binding Revocation Indication message as in Figure 5 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | B.R. Type = 1 | R. Trigger | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Sequence # |A|P|V|G| Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | | 511 . . 512 . Mobility options . 513 | | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 5: Binding Revocation Indication Message 518 Revocation Trigger 520 8-bit unsigned integer indicating the event which triggered the 521 revoking node to send the BRI message. The Reserved and Per-MN 522 Revocation Triggers value are less than 128 except the reserved 523 values 250-255. The per-MN revocation triggers is used when the 524 BRI message intends to revoke one or more bindings for the same 525 mobile node. The Global Revocation Trigger values are greater 526 than 128 and less than 250 and used in the BRI message with the 527 (G) bit set for global revocation. The following Revocation 528 Trigger values are currently defined: 530 Reserved and Per-MN Revocation Trigger: 531 0 Reserved 532 1 Unspecified 533 2 Administrative Reason 534 3 Inter-MAG Handover - same Access Type 535 4 Inter-MAG Handover - different Access Type 536 5 Inter-MAG Handover - Unknown 537 6 User Initiated Session(s) Termination 538 7 Access Network Session(s) Termination 539 8 Possible Out-of Sync BCE State 540 250-255 Reserved For Testing Purposes only 541 All other values are Reserved 543 Global Revocation Trigger: 544 128 Per-Peer Policy 545 129 Revoking Mobility Node Local Policy 547 Sequence # 549 A 16-bit unsigned integer used by the sending mobility node to 550 match a returned Binding Revocation Acknowledgement with this 551 Binding Revocation Indication. It could be a random number. 553 Acknowledge (A) 555 The Acknowledge (A) bit is set by the sending mobility node, e.g. 556 LMA, HA, or MAG, to request a Binding Revocation Acknowledgement 557 be returned upon receipt of the Binding Revocation Indication as 558 in Section 8.1, Section 9.1.1, and Section 10.2.1. 560 Proxy Binding (P) 562 The Proxy Binding (P) bit is set by the sending mobility node to 563 indicate that the revoked binding(s) is a PMIPv6 binding. 565 IPv4 HoA Binding Only (V) 567 The IPv4 HoA Binding Only (V) bit is set by the sending mobility 568 node, home agent or local mobility anchor, to request the 569 receiving mobility entity the termination of the IPv4 Home Address 570 binding only as in Section 8.1, and Section 9.1.1. 572 Global (G) 574 The Global (G) bit is set by the sending mobility node, LMA or 575 MAG, to request the termination of all Per-Peer mobility Bindings 576 or Multiple Bindings which share a common identifier that are 577 served by the sending and receiving mobility entities as in 578 Section 9.1.1 and Section 10.2.1. 580 Reserved 582 These fields are unused. They MUST be initialized to zero by the 583 sender and MUST be ignored by the receiver. 585 Mobility Options 587 Variable-length field of such length that the complete Mobility 588 Header is an integer multiple of 8 octets long. This field 589 contains zero or more TLV-encoded mobility options. This document 590 does not define any new mobility option. The receiver MUST ignore 591 and skip any options which it does not understand. These mobility 592 option(s) are used by the receiving mobility entity to identify 593 the specific binding or bindings that the sending mobility entity 594 requesting to be revoked. 596 The following options are valid in a Binding Revocation Indication: 598 o Home Network Prefix option [RFC5213]. This option MAY be used 599 when the (P) bit is set. This option MUST be present when the BRI 600 is used to revoke a single PMIP binding cache entry. 602 o Mobile Node Identifier Option [RFC4283]. This option is mandatory 603 when the (P) bit is set. Additionally, if the (G) bit is set by 604 the mobile access gateway, this option carries the MAG identity. 606 o Binding Identifier mobility option [ID-MCoA]. This option is 607 mandatory if the sending mobility entity requests to terminate one 608 binding of a multi care-of addresses bindings for the same mobile 609 node. The sending mobility entity may include more than one of 610 the BID mobility options. 612 o IPv4 Home Address option which contains the mobile node home IPv4 613 address [ID-DSMIP6]. This option is included only when the IPv4 614 HoA Binding only (V) bit is set. 616 o Alternate Care-of Address mobility option [RFC3775]. This option 617 MAY be included to indicate the Care-of Address of the mobile 618 node's binding that is being revoked. In the case when the Global 619 (G) bit set, this option identifies all the mobility bindings that 620 share the same care-of address. Additionally, if the Global (G) 621 bit set, more than one Alternate Care-of Address mobility options 622 MAY be present in the Binding Revocation Indication message. 624 If no options are present in this message, 4 octets of padding are 625 necessary and the Header Len field of the Binding Revocation Message 626 will be set to 1. 628 6.2. Binding Revocation Acknowledgement Message 630 The Binding Revocation Acknowledgement (BRA) message is a Binding 631 Revocation Message which has a MH type and a Binding 632 Revocation Type value of 2. It is used to acknowledge the receipt of 633 a Binding Revocation Indication message described in Section 6.1. 634 This packet is sent as described in Section 9.2.2, Section 10.1.2, 635 and Section 11.2. 637 When the value 2 is indicated in the Binding Revocation type field of 638 the Binding Revocation Message, the format of the Binding Revocation 639 Message Data follows the Binding Revocation Acknowledgement message 640 as in Figure 6 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | B.R. Type = 2 | Status | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Sequence # |P|V|G| Reserved | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | | 650 . . 651 . Mobility options . 652 . . 653 | | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Figure 6: Binding Revocation Acknowledgement Message 658 Status 660 8-bit unsigned integer indicating the result of processing the 661 Binding Revocation Indication message by the receiving mobility 662 entity. Values of the Status field less than 128 indicate that 663 the Binding Revocation Indication was processed successfully by 664 the receiving node. Values greater than or equal to 128 indicate 665 that the Binding Revocation Indication was rejected by the 666 receiving node. The following status values are currently 667 defined: 669 0 success 670 1 partial success 671 128 Binding Does NOT Exist 672 129 IPv4 Home Address Option Required 673 130 Global Revocation NOT Authorized 674 131 Revoked Mobile Nodes Identity Required 675 132 Revocation Failed - MN is Attached 676 133 Revocation Trigger NOT Supported 677 134 Revocation Function NOT Supported 679 Sequence # 681 The sequence number in the Binding Revocation Acknowledgement is 682 copied from the Sequence Number field in the Binding Revocation 683 Indication. It is used by the revoking mobility entity, e.g., HA, 684 LMA, MAG, in matching this Binding Revocation Acknowledgement with 685 the outstanding Binding Revocation Indication. 687 Proxy Binding (P) 689 The Proxy Binding (P) bit is set if the (P) bit is set in the 690 corresponding Binding Revocation Indication message. 692 IPv4 HoA Binding Only (V) 694 The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in 695 the corresponding Binding Revocation Indication message. 697 Global (G) 699 The Global (G) bit is set if the (G) bit is set in the 700 corresponding Binding Revocation Indication message. 702 Reserved 704 These fields are unused. They MUST be initialized to zero by the 705 sender and MUST be ignored by the receiver. 707 Mobility Options 709 Variable-length field of such length that the complete Mobility 710 Header is an integer multiple of 8 octets long. This field 711 contains zero or more TLV-encoded mobility options. In the case 712 when the Status field is set to success, no mobility option is 713 required. The mobility option(s) is usually used to communicate 714 information of the bindings that failed the revocation procedure. 716 The following mobility options are valid in a Binding Revocation 717 Acknowledgement: 719 o Home Network Prefix option [RFC5213]. This option MAY be included 720 when the (P) bit is set. 722 o Mobile Node Identifier Option [RFC4283]. This option MAY be 723 included when the (P) bit is set. This option SHOULD be included 724 if the Home Network Prefix option is included. 726 o Binding Identifier mobility option [ID-MCoA]. This option MAY be 727 included to indicate the specific BID that the receiving node 728 failed to revoke. 730 If no options are present in this message, 4 octets of padding are 731 necessary and the Header Len field of the Binding Revocation Message 732 will be set to 1. 734 7. Binding Revocation Process Operation 736 The following subsections describe the details of the binding 737 revocation generic process by the different mobility entities. 739 7.1. Sending Binding Revocation Messages 741 When sending a Binding Revocation message, the sending mobility node, 742 initiator, constructs the packet as it would any other Mobility 743 Header with the exception of setting the MH Type field to . 745 In addition, the mobility entity which initiates the binding 746 revocation process by sending a Binding Revocation Indication 747 message, initiator, MUST construct the Binding Revocation Message 748 Data following the format of the Binding Revocation Indication 749 message as described in Section 6.1. In the BRI message, the 750 initiator MUST set the Sequence Number field to the next sequence 751 number available for Binding Revocation. Since sending Binding 752 Revocation Indication message is not done on a regular basis, a 16 753 bit sequence number field is large enough to allow the initiator to 754 match the Binding Revocation Acknowledgement to the outstanding 755 Binding Revocation Indication with (A) bit set using the sequence 756 number field only. 758 However, when the responder acknowledges the Binding Revocation 759 Indication message, the responder MUST constructs the Binding 760 Revocation message packet as it would any other Mobility Header with 761 the exception of setting the MH Type field to . It also 762 MUST construct the Binding Revocation Message Data following the 763 format of the Binding Revocation Acknowledgement message as described 764 in Section 6.2. In this case, the responder MUST set the Sequence 765 Number field by copying the value from the Sequence Number field of 766 the received Binding Revocation Indication. Additionally, it MUST 767 set the status field to a valid value that reflects the processing of 768 the received Binding Revocation Indication. 770 A mobility entity MUST secure Binding Revocation Indication and 771 Binding Revocation Acknowledgement messages with the same underlying 772 security association, e.g., IPsec SA, that has been used to secure 773 the mobile node binding registration signaling. 775 7.2. Receiving Binding Revocation Messages 777 When receiving a Binding Revocation message, the receiving mobility 778 node MUST verify the Mobility Header as described in section 9.2. of 779 [RFC3775]. If the packet is dropped due to failing any of the 780 Mobility Headers test check, the receiving node MUST follow the 781 processing rules as in Section 9.2 of [RFC3775]. If the receiving 782 node does not support the Binding Revocation Indication message and 783 does not recognize the new MH type, it sends a Binding Error message 784 with the Status field set to 2 as described in [RFC3775]. 786 Since some mobility entities, e.g., local mobility anchor and mobile 787 access gateway, are allowed to receive and possibly send a Binding 788 Revocation Indication or Binding Revocation Acknowledgement for 789 different cases, therefore, if IPsec is used to secure signaling 790 between the them, it prevents any possible man in the middle 791 reflection attack. 793 Upon receiving a packet carrying a Binding Revocation Indication or 794 Binding Revocation Acknowledgement, the receiving mobility entity 795 verifies that the packet was received protected with the security 796 association that has been used during the binding registration 797 signaling phase, e.g., an IPsec SA. 799 Upon receiving a packet carrying a Binding Revocation 800 Acknowledgement, the receiving mobility entity, initiator, MUST 801 validate that sequence number in the Sequence Number field matches 802 the sequence number of an outstanding Binding Revocation Indication 803 that was sent by the initiator. If the sequence number does not 804 match any sequence number of any of the outstanding Binding 805 Revocation Indication, the receiving node MUST silently discard the 806 message but MAY log the event. 808 If a mobility node receives a Binding Revocation Indication message 809 with the Revocation Trigger field is set to a value that NOT 810 supported, the receiving mobility node SHOULD reject the Binding 811 Revocation Indication message by sending a Binding Revocation 812 Acknowledgement message with the Status field set to "Revocation 813 Trigger NOT Supported". 815 If a mobility node receives a Binding Revocation Indication message 816 with a Revocation Trigger value that is NOT in line with the Binding 817 Revocation Indication message intent, e.g., the Global Revocation (G) 818 bit set and the Revocation Trigger field vale is a per-MN specific, 819 the receiving mobility node SHOULD reject the Binding Revocation 820 Indication message by sending a Binding Revocation Acknowledgement 821 message with the Status field set to "Revocation Function NOT 822 Supported". 824 7.3. Retransmission of Binding Revocation Indication 826 If the sending mobility entity does not receive a Binding Revocation 827 Acknowledgement in response to the outstanding Binding Revocation 828 Indication before the MINDelayBRIs timer expires, the mobility 829 entity, e.g. LMA, may retransmit the same BRI message up to the 830 BRIMaxRetriesNumber as defined in Section 12. If the revoking 831 mobility entity does not receive a Binding Revocation Acknowledgement 832 message after the maximum number of retransmits have been sent, the 833 revoking mobility entity can clean the mobile node binding cache and 834 all resources associated with this binding. The revoking mobility 835 entity may log the event. 837 8. Home Agent Operation 839 8.1. Sending Binding Revocation Indication 841 To terminate a mobile node registration and its current binding with 842 the home agent, the home agent sends a packet to the mobile node 843 containing a Binding Revocation Indication, with the packet 844 constructed as follows: 846 o The Acknowledge (A) bit MAY be set to request the mobile node to 847 send a Binding Revocation Acknowledgement upon receipt of the 848 Binding Revocation Indication. 850 o The Revocation Trigger field MUST be set to indicate to the mobile 851 node the reason for revoking its IP mobility binding with the home 852 agent. The Revocation Trigger may be used by the mobile node to 853 take further steps if necessary. 855 o The Binding Revocation Indication MUST be sent using a Type 2 856 routing header which contains the mobile node's registered IPv6 857 home address for the binding being revoked. 859 o The care-of address for the binding MUST be used as the 860 destination address in the packet's IPv6 header, unless an 861 Alternate Care-of Address mobility option is included in the 862 Binding Revocation Indication. 864 o If the home agent needs to only revoke the mobile node's IPv4 home 865 address binding, the home agent MUST set the IPv4 HoA Binding Only 866 (V) bit and MUST include the mobile node's registered IPv4 home 867 address that is being revoked in the IPv4 Home Address option. 869 The Acknowledge (A) bit in the Binding Revocation Indication requests 870 the mobile node to return a Binding Revocation Acknowledgement in 871 response to this Binding Revocation Indication. As described in 872 Section 7.3, the home agent SHOULD retransmit this Binding Revocation 873 Indication to the mobile node before terminating its IP connection 874 until it receives a matching Binding Revocation Acknowledgement or 875 the BRIMaxRetransmitNumber has been reached. 877 When the home agent sends a Binding Revocation Indication to the 878 mobile node with the (A) bit set, the home agent sets a flag in the 879 mobile node BCE to indicate that revocation is in progress and starts 880 the MINDelayBRIs timer. The home agent maintains the mobile node BCE 881 in this state until it receives a Binding Revocation Acknowledgement 882 or the BRIMaxRetransmitNumber is reached. 884 In a race condition case, the home agent may receive a Binding Update 885 from the mobile node while the mobile node's BCE has the revocation 886 in progress flag set, the home agent SHOULD handle this case based on 887 the reason for sending the Binding Revocation Indication message and 888 its local policy. In this case, if the home agent accepts the 889 Binding Update, it needs to update the mobile node BCE accordingly, 890 e.g. removing the revocation in progress flag. 892 When the home agent needs to revoke one or more of a mobile node 893 bindings that were created using Multi Care-of address registration 894 as in [ID-MCoA], the home agent MUST include all the related BID 895 mobility options that identify these bindings in the Binding 896 Revocation Indication message. In the case when the home agent needs 897 to revoke all of the mobile node bindings, the home agent SHOULD NOT 898 include any of the BID mobility options. 900 8.2. Receiving Binding Revocation Acknowledgement 902 When the home agent receives a packet carrying a valid Binding 903 Revocation Acknowledgement that was successfully processed as in 904 Section 7.2, the home agent SHOULD examine the Status field as 905 follows: 907 o If the Status field indicates that the Binding Revocation 908 Indication was processed successfully, the home agent deletes the 909 MINDelayBRIs timer and the mobile node bindings and all related 910 resources. 912 o If the Status field indicates any value other than success, the 913 home agent SHOULD examine any mobility options included in the 914 Binding Revocation Acknowledgement. The home agent MAY log the 915 appropriate event to reflect the received status. 917 9. Local Mobility Anchor Operation 919 9.1. Binding Revocation Initiator 921 9.1.1. Sending Binding Revocation Indication 923 To terminate a mobile node PMIPv6 registration and its current 924 binding with the local mobility anchor, the local mobility anchor 925 sends a packet to the mobile access gateway containing a Binding 926 Revocation Indication message following the procedure in Section 7.1 927 and the following rules: 929 o The Acknowledge (A) bit MAY be set to request the mobile access 930 gateway to send a Binding Revocation Acknowledgement upon receipt 931 of the Binding Revocation Indication. 933 o The Proxy Mobile IP (P) bit MUST be set to indicate that the 934 binding being revoked is a PMIPv6 binding. 936 o The Revocation Trigger field MUST be set to indicate to the mobile 937 access gateway the reason for removing the specified mobile node 938 PMIPv6 binding at the local mobility anchor. The Revocation 939 Trigger may be used by the mobile access gateway to learn the 940 mobile node's latest movement. 942 o In case of revoking all Per-Peer bindings, the Global (G) bit MUST 943 be set and the Revocation Trigger MUST contain a value of "Per- 944 Peer Policy" to request the mobile access gateway to remove all 945 Per-Peer bindings that are registered with the local mobility 946 anchor and hosted at this mobile access gateway. 948 o Whenever the Global (G) bit is set in the Binding Revocation 949 Indication, the Acknowledge (A) bit MUST be set to request the 950 mobile access gateway to send a Binding Revocation 951 Acknowledgement. 953 o The packet MUST contain the Mobile Node Identifier, MN-ID, option 954 which contains the mobile node's NAI that was used in the Proxy 955 Binding Update during the mobile node registration. 957 o If the Mobile Node Identifier, MN-ID, is registered in more than 958 one of the mobile node's BCE and the local mobility anchor does 959 NOT need to revoke all of the mobile node's bindings, the packet 960 MUST contain another identifier to uniquely identify the mobile 961 node binding(s) that is being revoked, e.g., at least one Home 962 Network Prefix option which contains the mobile node's registered 963 HNP for the binding being revoked. 965 o The care-of address for the binding MUST be used as the 966 destination address in the packet's IPv6 header, unless an 967 Alternate Care-of Address mobility option is included in the 968 Binding Revocation Indication message. 970 The Acknowledge (A) bit in the Binding Revocation Indication requests 971 the mobile access gateway to return a Binding Revocation 972 Acknowledgement. As described in Section 7.3, the local mobility 973 anchor SHOULD retransmit this Binding Revocation Indication before 974 deleting the mobile node IP tunnel to the mobile access gateway until 975 it receives a matching Binding Revocation Acknowledgement or the 976 BRIMaxRetransmitNumber is reached. The local mobility anchor MAY 977 delete the mobile node(s) IP tunnel immediately after sending the 978 Binding Revocation Indication and before receiving the Binding 979 Revocation Acknowledgement message. 981 When the local mobility anchor sends a Binding Revocation Indication 982 to the mobile access gateway to remove a specific binding and the 983 Acknowledge (A) bit is set, the local mobility anchor sets a flag in 984 the mobile node proxy BCE to indicate that revocation is in progress 985 and starts the MINDelayBRIs timer. The local mobility anchor SHOULD 986 maintain the mobile node proxy BCE in this state until it receives a 987 Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is 988 reached. In the case when the local mobility anchor sets the 989 Revocation Trigger field to a value which indicates inter-MAG 990 handover, the local mobility anchor MAY switch the mobile node IP 991 tunnel to the target mobile access gateway before sending the Binding 992 Revocation Indication to the source mobile access gateway. 994 In a race condition case, the local mobility anchor may receive a 995 Proxy Binding Update from the mobile access gateway while the mobile 996 node's proxy BCE has the revocation in progress flag set, the local 997 mobility anchor should handle this case based on the reason for 998 sending the Binding Revocation Indication message and its local 999 policy. In this case, if the local mobility anchor accepts the Proxy 1000 Binding Update, it needs to update the mobile node proxy BCE 1001 accordingly, e.g. removing the revocation in progress flag. 1003 When the local mobility anchor needs to revoke all mobile nodes proxy 1004 BCE that are registered with the local mobility anchor and hosted at 1005 the mobile access gateway, it MUST set the Global (G) bit and set the 1006 value of the Revocation Trigger field to "Per-Peer Policy". In this 1007 case, the local mobility anchor MUST NOT include any mobility options 1008 in the this Binding Revocation Indication message. 1010 When the local mobility anchor needs to revoke all mobile nodes proxy 1011 BCE that belong to a specific realm, e.g. @companyabc.com, that are 1012 registered with the local mobility anchor and hosted at the mobile 1013 access gateway, the local mobility anchor MUST set the Global (G) bit 1014 and set the value of the Revocation Trigger field to "Revoking 1015 Mobility Node Local Policy". In this case, the local mobility anchor 1016 MUST include a mobility option in the Binding Revocation Indication 1017 to identify the impacted bindings, e.g., MN-ID option with a wildcard 1018 NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs 1019 that need to be removed. 1021 When the mobile node is registered with multiple Home Network 1022 Prefixes for the same proxy care-of address, the local mobility 1023 anchor SHOULD include a HNP option for each registered HNP in the 1024 Binding Revocation Indication. Alternatively, it MAY include only 1025 the mobile node identifier, MN-ID, option to indicate to the mobile 1026 access gateway to remove all bindings of the specified mobile node 1027 NAI in the MN-ID option. 1029 When the mobile node is registered with an IPv4 proxy home address in 1030 addition to the Home Network Prefix where both of the IPv4 pHoA and 1031 HNP are bound to the same proxy CoA, the local mobility anchor MAY 1032 revoke the mobile node IPv4 proxy HoA binding to the current mobile 1033 node proxy CoA while maintaining the mobile node binding of the HNP 1034 to its current pCoA as part of the mobile node BCE. In this case, if 1035 the local mobility anchor decides to revoke the mobile node IPv4 1036 proxy HoA ONLY, it MUST send a Binding Revocation Indication message 1037 following the procedure in Section 7.1 and the following rules: 1039 o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to 1040 indicate that only the IPv4 home address binding is being revoked. 1042 o The Acknowledge (A) bit MUST be set to request the mobile access 1043 gateway to send a Binding Revocation Acknowledgement message. 1045 o The IPv4 Home Address option MUST be included with the mobile 1046 node's registered IPv4 home address that is being released in 1047 addition to the MN-ID option. 1049 o The mobile node Home Network Prefix option MUST NOT be included. 1051 o The Revocation Trigger field MUST be set to an appropriate value, 1052 e.g. "User Initiated Session(s) Termination". 1054 9.1.2. Receiving Binding Revocation Acknowledgement 1056 When the local mobility anchor receives a packet carrying a valid 1057 Binding Revocation Acknowledgement that was successfully processed as 1058 in Section 7.2 and if the mobile node BCE is in the state of 1059 Revocation in progress, the local mobility anchor SHOULD examine the 1060 Status field before clearing the mobile node related resources as 1061 follows: 1063 o If the Status field indicates that the BRI was processed 1064 successfully, the local mobility anchor delete the MINDelayBRIs 1065 timer and the mobile node proxy bindings and all associated 1066 resources. 1068 o If the Status field indicates partial success value or MN binding 1069 does not exist, the local mobility anchor SHOULD examine mobility 1070 options that are included in the Binding Revocation 1071 Acknowledgement, if any, before deleting the MINDelayBRIs timer 1072 and the mobile node associated proxy bindings and other related 1073 resources. It is based on the local mobility anchor local policy 1074 how to handle the mobile node BCE(s) that the mobile access 1075 gateway indicated it failed the revocation procedure, however, the 1076 LMA MAY log the event. 1078 9.2. Binding Revocation Responder 1079 9.2.1. Receiving Binding Revocation Indication 1081 When the local mobility anchor receives a packet carrying a Binding 1082 Revocation Indication that was successfully processed as in 1083 Section 7.2, the local mobility anchor SHOULD in addition process the 1084 message as follows: 1086 o Binding Revocation Indication is formatted as in Section 6.1 and 1087 if the (P) bit is set, the local mobility anchor MUST validate 1088 that all impacted binding(s) have the proxy binding flag set. 1090 o If the Global (G) bit is set and the Revocation Trigger value is 1091 "Per-Peer Policy", the Proxy (P) bit MUST be set and the Binding 1092 Revocation Indication SHOULD contain the mobile access gateway ID 1093 in the MN-ID option. The local mobility anchor MUST verify that 1094 the identified mobile access gateway as per the value in the MN-ID 1095 option is authorized to use the Global revocation. The mechanism 1096 the local mobility anchor uses to verify the mobile access gateway 1097 authorization is out of scope of this document. 1099 o If the Global (G) bit is set and the Revocation Trigger value is 1100 "Per-Peer Policy", and only the mobile node identifier, MN-ID, 1101 option is included, the local mobility anchor MUST revoke all 1102 mobile nodes bindings which proxy CoA is the one used as the 1103 source of the IPv6 packet that carried the Binding Revocation 1104 Indication. However, if one or more Alternate Care-of Address 1105 options are included in addition to the mobile node identifier 1106 option, the local mobility anchor MUST revoke all mobile nodes 1107 bindings which proxy Care-of Address matches one of the Care-of 1108 address(es) in the Alternate Care-of Address option(s). 1110 o The local mobility anchor identifies all impacted mobile nodes 1111 bindings and if the Acknowledgement (A) bit is set, the local 1112 mobility anchor MUST send a Binding Revocation Acknowledgement 1113 following Section 9.2.2 using the appropriate status code. 1115 o If the Global (G) bit is NOT set, the local mobility anchor SHOULD 1116 use the included mobility options to identify the impacted mobile 1117 node binding as follows: 1119 1. If only the mobile node identifier, MN-ID, option is included, 1120 the local mobility anchor MUST revoke all bindings for this 1121 mobile node which use the specified mobile node NAI. 1123 2. If the mobile node identifier, MN-ID, and the Home Network 1124 Prefix option are included, the local mobility anchor MUST 1125 only remove the specified proxy binding. 1127 3. If the mobile node identifier, MN-ID, option and more than one 1128 Home Network Prefix options are included, the local mobility 1129 anchor MUST remove all bindings which are referenced by these 1130 multiple Home Network Prefixes for the specified mobile node 1131 NAI. 1133 The Revocation Trigger field value in the received Binding Revocation 1134 Indication could be used by the local mobility anchor to log an event 1135 or update some local parameters which tracks the state of the peer 1136 mobile access gateway. 1138 9.2.2. Sending Binding Revocation Acknowledgement 1140 When the local mobility anchor receive a valid Binding Revocation 1141 Indication with the (A) bit set and after processing the Binding 1142 Revocation Indication message, the local mobility anchor sends a 1143 packet to the mobile access gateway containing a Binding Revocation 1144 Acknowledgement following the process in Section 7.1 and the 1145 following: 1147 o If the (P) bit was set in the received Binding Revocation 1148 Indication, the local mobility anchor MUST set the (P) bit in the 1149 Binding Revocation Acknowledgement. 1151 o If the Global (G) bit was set in the received Binding Revocation 1152 Indication, the local mobility anchor MUST set the (G) bit in the 1153 Binding Revocation Acknowledgement. 1155 o If the IPv4 HoA Binding Only (V) bit was set in the received 1156 Binding Revocation Indication, the local mobility anchor MUST set 1157 the (V) bit in the Binding Revocation Acknowledgement. 1159 o The local mobility anchor MUST set the Status field to a valid 1160 code that reflects the processing of the received Binding 1161 Revocation Indication. If the mobile access gateway is not 1162 authorized to use the Per-Peer Global revocation feature, the 1163 local mobility anchor MUST set the Status field to (Global 1164 Revocation NOT Authorized). 1166 o In the case that one of the bindings identified in the received 1167 Binding Revocation Indication message has already been released 1168 before receiving the it, the local mobility anchor MAY set the 1169 Status field to partial success and in this case it MAY include 1170 the mobile node identifier or the Home Network Prefix option to 1171 identify the binding(s) that failed revocation. 1173 o The destination IP address of the IPv6 packet of the Binding 1174 Revocation Acknowledgement is set to the source IP address of the 1175 received Binding Revocation Indication. 1177 10. Mobile Access Gateway Operation 1179 10.1. Binding Revocation Responder 1181 10.1.1. Receiving Binding Revocation Indication 1183 Upon receiving a packet carrying a Binding Revocation Indication, the 1184 mobile access gateway MUST validate the packet according to 1185 Section 7.2 and the following: 1187 o Binding Revocation Indication MUST be formatted as in Section 6.1 1188 and the (P) bit is set. 1190 o If the Acknowledgement (A) bit in the received Binding Revocation 1191 Indication is set, the mobile access gateway MUST send a Binding 1192 Revocation Acknowledgement following Section 10.1.2 using the 1193 appropriate status value. 1195 o If the Global (G) bit is set and the Revocation Trigger field 1196 value is "Per-Peer policy", the mobile access gateway identifies 1197 all bindings that are registered at the local mobility anchor and 1198 hosted at the mobile access gateway. This Binding Revocation 1199 Indication does not include any other mobility options. In this 1200 case, the mobile access gateway MUST send a Binding Revocation 1201 Acknowledgement with the appropriate status code to the local 1202 mobility anchor. 1204 o If the Global (G) bit is set and the Revocation Trigger field 1205 value is "Revoking Mobility Node Local Policy", the mobile access 1206 gateway MUST identify all bindings that are registered at the 1207 local mobility anchor and hosted at the mobile access gateway 1208 using the mobility option(s) included in the Binding Revocation 1209 Indication which SHOULD include at least the MN-ID option, e.g., 1210 with a wild card NAI. In this case, the mobile access gateway 1211 MUST send a Binding Revocation Acknowledgement with the 1212 appropriate status code to the local mobility anchor. 1214 o If the Global (G) bit is set and the Revocation Trigger field 1215 value is "Revoking Mobility Node Local Policy", and no mobility 1216 options are included in the Binding Revocation Indication message 1217 or the mobile access gateway is not able to identify the impacted 1218 mobile nodes bindings based on the included mobility options, the 1219 mobile access gateway MUST treat this as an error scenario. In 1220 this case, the mobile access gateway SHOULD send a Binding 1221 Revocation Acknowledgement message with status "Revoked Mobile 1222 Nodes Identity Required". 1224 o If the Revocation Trigger field value in the received Binding 1225 Revocation Indication message indicates inter-MAG handover, e.g., 1226 Inter-MAG Handover - Unknown, and the (A) bit is set, the mobile 1227 access gateway use the mobility option(s) included in the Binding 1228 Revocation Indication message to identify the mobile node binding. 1229 The mobile access gateway SHOULD validate that the mobile node is 1230 no longer attached to the mobile access gateway before sending a 1231 successful Binding Revocation Acknowledgement message to the local 1232 mobility anchor. However, if the mobile access gateway verified 1233 that the mobile node is still directly attached, the mobile access 1234 gateway MUST set the status field in the Binding Revocation 1235 Acknowledgement to "Revocation failed - MN is Attached". 1237 o If the IPv4 HoA Binding Only (V) bit in the received Binding 1238 Revocation Indication message is set, the mobile access gateway 1239 uses the MN-ID option to identify the mobile node binding entry in 1240 the BUL. It MUST verify that the IPv4 address included in the 1241 IPv4 Home Address option in the received Binding Revocation 1242 Indication is the same as the IPv4 proxy HoA that is assigned to 1243 the mobile node. After the mobile access gateway successfully 1244 validates the received IPv4 home address as the mobile node IPv4 1245 HoA, it MUST consider this as an indication to release the mobile 1246 node IPv4 proxy HoA binding to the mobile node current proxy CoA 1247 ONLY. Consequently, it MUST continue to maintain the mobile node 1248 IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA 1249 as part of the mobile node binding in the BUL entry and release 1250 all resources associated with the MN IPv4 proxy HoA binding to the 1251 MN pCoA. In this case, the mobile access gateway MUST send a 1252 Binding Revocation Acknowledgement message with the Status field 1253 is set to success. On the other hand, if the mobile access 1254 gateway is able to identify the mobile node binding using the 1255 MN-ID but failed to identify the received IPv4 proxy HoA, it MUST 1256 send a Binding Revocation Acknowledgement with Status field is set 1257 to "Binding Does NOT Exist". 1259 The Revocation Trigger field value in the received Binding Revocation 1260 Indication could be used by the mobile access gateway to define what 1261 actions the mobile access gateway could do to inform the mobile node 1262 that its IP connectivity to the current HNP has been terminated, 1263 e.g., if the Revocation Trigger field is set to "Administrative 1264 Reason", the mobile access gateway may send a RA message after 1265 setting the Home Network Prefix valid lifetime to zero. 1267 10.1.2. Sending Binding Revocation Acknowledgement 1269 When the mobile access gateway receive a valid Binding Revocation 1270 Indication with the (A) bit set and after processing it, the mobile 1271 access gateway sends a packet to the local mobility anchor containing 1272 a Binding Revocation Acknowledgement according to the procedure in 1273 Section 7.1 and the following: 1275 o The mobile access gateway MUST set the (P) bit in the Binding 1276 Revocation Acknowledgement if it is set in the received Binding 1277 Revocation Indication. 1279 o If the Global (G) bit was set in the received Binding Revocation 1280 Indication, the mobile access gateway MUST set the (G) bit in the 1281 Binding Revocation Acknowledgement. 1283 o If the IPv4 HoA Binding Only (V) bit was set in the received 1284 Binding Revocation Indication, the mobile access gateway MUST set 1285 the (V) bit in the Binding Revocation Acknowledgement. 1287 o The mobile access gateway MUST set the Status field to a valid 1288 code that reflects the processing of the received Binding 1289 Revocation Indication. 1291 o In the case that one or more of the bindings identified in the 1292 received Binding Revocation Indication message has already been 1293 released before receiving the Binding Revocation Indication, the 1294 mobile access gateway MAY set the Status field to "partial 1295 success" and include the mobile node identifier, MN-ID, or the 1296 Home Network Prefix option to identify the binding(s) that failed 1297 to be removed as part of the revocation procedure. 1299 o The destination IP address of the IPv6 packet of the Binding 1300 Revocation Acknowledgement is set to the source IP address of the 1301 received Binding Revocation Indication. 1303 10.2. Binding Revocation Initiator 1305 10.2.1. Sending Binding Revocation Indication 1307 The mobile access gateway could send a Binding Revocation Indication 1308 message to indicate the termination of multiple mobile node bindings, 1309 e.g., when using the global revocation with the Global (G) bit set. 1310 In this case when an event occurs which requires the mobile access 1311 gateway to inform the local mobility anchor to terminate all mobile 1312 nodes bindings which are registered at the local mobility anchor and 1313 the mobile access gateway, the mobile access gateway sends a Binding 1314 Revocation Indication message following Section 7.1 and the 1315 following: 1317 o The Acknowledge (A) bit MUST be set in the to request the local 1318 mobility anchor to send a Binding Revocation Acknowledgement upon 1319 receipt of the Binding Revocation Indication. 1321 o The Proxy Binding (P) bit MUST be set to indicate that bindings 1322 that being revoked is a PMIPv6 binding. 1324 o The Global (G) bit MUST be set and the Revocation Trigger MUST 1325 contain a value of "Per-Peer Policy" in the Binding Revocation 1326 Indication to request the local mobility anchor to remove all Per- 1327 Peer bindings that are registered with the local mobility anchor 1328 and hosted at this mobile access gateway. In this case, the MN-ID 1329 option MUST be included in the Binding Revocation Indication and 1330 contain the mobile access gateway identity. In addition, the 1331 mobile access gateway MAY include one or more Alternate Care-of 1332 Address option(s). The Alternate Care-of Address option(s) 1333 contain the proxy Care-of address(es) which their bindings are 1334 being impacted by this Binding Revocation Indication message. 1336 o The mobile access gateway address MAY be used as the source 1337 address in the packet's IPv6 header. 1339 The Acknowledge (A) bit in the Binding Revocation Indication requests 1340 the local mobility anchor to return a Binding Revocation 1341 Acknowledgement in response to this Binding Revocation Indication. 1342 As described in Section 7.3, the mobile access gateway SHOULD 1343 retransmit this Binding Revocation Indication to the local mobility 1344 anchor until it receives a matching Binding Revocation 1345 Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile 1346 access gateway MAY delete the mobile nodes IP tunnels immediately 1347 after sending the Binding Revocation Indication and before receiving 1348 a Binding Revocation Acknowledgement message from the LMA. 1350 10.2.2. Receiving Binding Revocation Acknowledgement 1352 When the mobile access gateway receives a packet carrying a valid 1353 Binding Revocation Acknowledgement that was successfully processed 1354 according to Section 7.2, the mobile access gateway MUST process the 1355 received Binding Revocation Acknowledgement as per the followings: 1357 o When the mobile access gateway receives a packet carrying a valid 1358 Binding Revocation Acknowledgement and the Global (G) and Proxy 1359 Binding (P) bits are set and the mobile nodes BCEs are in the 1360 state of Revocation in Progress, the mobile access gateway SHOULD 1361 examine the Status field as follows: 1363 o If the Status field indicates that the Binding Revocation 1364 Indication was processed successfully, the mobile access gateway 1365 delete the MINDelayBRIs timer and the mobile nodes proxy bindings 1366 and all associated resources. 1368 o If the Status field indicates (Global Revocation NOT Authorized), 1369 the mobile access gateway is not authorized to participate in a 1370 Per-Peer Global Revocation. The mobile access gateway SHOULD NOT 1371 retry sending a Binding Revocation Indication with the Global (G) 1372 bit set to the same local mobility agent. The mobile access 1373 gateway should raise an alarm or log an event to indicate this 1374 rejection. 1376 11. Mobile Node Operation 1378 11.1. Receiving Binding Revocation Indication 1380 Upon receiving a packet carrying a Binding Revocation Indication, the 1381 mobile node MUST validate the packet according to Section 7.2 and the 1382 following tests: 1384 o The mobile node MUST verify that the IP address in the Type 2 1385 routing header is its Home Address and that its Binding Update 1386 List contains an entry for that Home Address. If one of the 1387 tests, fails the mobile node SHOULD silently discard the received 1388 Binding Revocation Indication message. 1390 o If the Acknowledgement (A) bit is set in the Binding Revocation 1391 Indication and its Binding Update List contains an entry for the 1392 IP address in the Type 2 routing header, the mobile node MUST send 1393 a Binding Revocation Acknowledgement. However, in all other cases 1394 when the (A) bit is set in the BRI, the mobile node SHOULD send a 1395 Binding Revocation Acknowledgement. In all cases, the mobile node 1396 MUST follow Section 11.2 and send a Binding Revocation 1397 Acknowledgement using the appropriate status code. 1399 o If the IPv4 HoA Binding Only (V) bit is set in the received BRI 1400 message, the mobile node MUST verify that there is an IPv4 Home 1401 Address option in the received Binding Revocation Indication and 1402 the IPv4 address included in the IPv4 Home Address option is the 1403 same as its IPv4 HoA that is assigned to the mobile node. If this 1404 verification is successful, the mobile node MUST consider this 1405 Binding Revocation Indication as an indication to release the 1406 mobile node IPv4 HoA binding ONLY to its current Care-of Address. 1407 Consequently, the mobile node MUST continue to maintain its IPv6 1408 HoA binding to the current CoA as part of the mobile node binding 1409 in the BUL entry and release all resources associated with the MN 1410 IPv4 HoA binding. In this case, the mobile node MUST send a 1411 Binding Revocation Acknowledgement message with the Status field 1412 is set to "success". On the other hand, if the IPv4 Home Address 1413 Option was NOT included in the received BRI with the (V) bit set, 1414 the MN SHOULD send a Binding Revocation Acknowledgement message 1415 with the Status field set to "IPv4 Home Address Option Required". 1416 Additionally, if the IPv4 HoA received in the IPv4 Home Address 1417 Option is NOT the one assigned to the mobile node, the mobile node 1418 SHOULD send a Binding Revocation Acknowledgement with the status 1419 field set to "Binding Does NOT Exist". 1421 o The mobile node MUST verify that the (P) bit in the Binding 1422 Revocation Indication is NOT set. If the (P) bit is set, the 1423 mobile node MUST silently discard the Binding Revocation 1424 Indication message. 1426 o If the mobile node has registered multiple care-of addresses with 1427 its home agent, the mobile node MUST verify which binding is being 1428 revoked by examining the content of the Binding Revocation 1429 Indication message. If the mobile node received a Binding 1430 Revocation Indication with a single or more than one BID options 1431 and its home address is included in the Type 2 routing header, the 1432 mobile node MUST consider all of the care-of address(es) 1433 binding(s), identified in the BID options, with this home address 1434 are being revoked. 1436 o If the mobile node has multi Care-of Address bindings with its 1437 home agent and received a Binding Revocation Indication, without 1438 any BID option included and its home address was included in the 1439 Type 2 routing header, the mobile node MUST consider all of its 1440 registered care-of addresses bindings with this home address are 1441 being revoked. 1443 The Revocation Trigger field value in the received Binding Revocation 1444 Indication could be used by the mobile node to define what action the 1445 mobile node could do to be able to register again and receive its IP 1446 mobility service, e.g., contacting its home operator. 1448 11.2. Sending Binding Revocation Acknowledgement 1450 When the mobile node receives a Binding Revocation Indication from 1451 its home agent, the mobile node processes the received Binding 1452 Revocation Indication as in Section 11.1. If the mobile node is 1453 required to send a Binding Revocation Acknowledgement message in 1454 response to the received Binding Revocation Indication, the mobile 1455 node sends a packet to its home agent containing a Binding Revocation 1456 Acknowledgement according to the procedure in Section 7.1 and the 1457 following: 1459 o The mobile node MUST set the Status field to an appropriate value. 1460 The mobile node sets the Status field to success to reflect that 1461 it has received the Binding Revocation Indication and acknowledge 1462 that its IP connectivity with its home agent has been revoked. 1464 o The destination IP address of the IPv6 packet of the Binding 1465 Revocation Acknowledgement is set to the source IP address of the 1466 received IPv6 packet of the Binding Revocation Indication. The 1467 Mobile Node MUST include its home address in the Home Address 1468 Destination Option. 1470 12. Protocol Configuration Variables 1472 Any mobility entity which is allowed to invoke the binding revocation 1473 procedure by sending a Binding Revocation Indication message SHOULD 1474 allow the following variables to be configured. 1476 BRI Maximum Number of Retries (BRIMaxRetriesNumber) 1478 This variable specifies the maximum Number of times a mobility 1479 entity can retransmit a Binding Revocation Indication message 1480 before receiving a Binding Revocation Acknowledgement message. 1481 The default value for this parameter is 1. 1483 Minimum Delay Between BRI messages (MINDelayBRIs) 1485 This variable specifies the delay time in seconds before the 1486 revoking mobility entity retransmits a BRI message. The default 1487 is 1 second but not less than 0.5 seconds. 1489 13. IANA Considerations 1491 This specification defines a new Binding Revocation Message using a 1492 new Mobility Header Type , as described in Section 6. The 1493 new Mobility Header type value needs to be assigned from the same 1494 numbering space as allocated for the other Mobility Header types. 1496 This document also creates a new name space "Binding Revocation Type" 1497 which indicates the type of the binding revocation message. The 1498 current binding revocation message types are described in Section 6.1 1499 and Section 6.2, and are the following: 1501 0 Reserved 1502 1 Binding Revocation Indication 1503 2 Binding Revocation Acknowledgement 1504 All other values are reserved 1506 Future values of the Binding Revocation Type can be allocated using 1507 Standards Action or IESG Approval [RFC2434]. 1509 In addition, this document also creates a second new namespace for 1510 the Revocation Trigger which indicates the reason behind sending the 1511 Binding Revocation Indication message. The current Revocation 1512 Trigger values are described in Section 6.1, and are the following: 1514 Reserved and Per-MN Revocation Trigger Values: 1515 0 Reserved 1516 1 Unspecified 1517 2 Administrative Reason 1518 3 Inter-MAG Handover - same Access Type 1519 4 Inter-MAG Handover - different Access Type 1520 5 Inter-MAG Handover - Unknown 1521 6 User Initiated Session(s) Termination 1522 7 Access Network Session(s) Termination 1523 8 Possible Out-of Sync BCE State 1524 250-255 Reserved For Testing Purposes only 1525 All other values are Reserved 1527 Global Revocation Trigger Values: 1528 128 Per-Peer Policy 1529 129 Revoking Mobility Node Local Policy 1531 Future values of the Revocation Trigger can be allocated using 1532 Standards Action or IESG Approval [RFC2434]. 1534 Furthermore, this document creates a third new name space "Status 1535 Code" for the Status field in the Binding Revocation Acknowledgement 1536 message. The current values are described in Section 6.2, and are 1537 the following: 1539 0 success 1540 1 partial success 1541 128 Binding Does NOT Exist 1542 129 IPv4 Home Address Option Required 1543 130 Global Revocation NOT Authorized 1544 131 Revoked Mobile Nodes Identity Required 1545 132 Revocation Failed - MN is Attached 1546 133 Revocation Trigger NOT Supported 1547 134 Revocation Function NOT Supported 1549 Future values of the Status field can be allocated using Standards 1550 Action or IESG Approval [RFC2434]. 1552 All fields labeled "Reserved" are only to be assigned through 1553 Standards Action or IESG Approval. 1555 14. Security Considerations 1557 The protocol described here uses the same security association 1558 between the mobile node and the home agent or the mobile access 1559 gateway and the local mobility anchor that has been used to exchange 1560 the corresponding MIPv6 or PMIPv6 Binding Update and Binding 1561 Acknowledgement when the session was established. If IPsec is used, 1562 the SPD of this IPsec SA MUST allow the MH type for the Binding 1563 Revocation Message defined in this document. 1565 However, in the case when the mobile access gateway sends a Binding 1566 Revocation Indication message with the Global (G) bit is set and the 1567 Revocation Trigger field is set to "Per-Peer policy", the local 1568 mobility anchor MUST verify that the mobile access gateway is 1569 authorized to use Per-Peer Global Revocation. 1571 15. Acknowledgements 1573 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1574 Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay 1575 Devarapalli, and Joel Hortelius for their review and comments of this 1576 draft and all colleagues who have supported the advancement of this 1577 draft effort. 1579 16. References 1581 16.1. Normative References 1583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1584 Requirement Levels", BCP 14, RFC 2119, March 1997. 1586 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1587 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1588 October 1998. 1590 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1591 in IPv6", RFC 3775, June 2004. 1593 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1594 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1595 (MIPv6)", RFC 4283, November 2005. 1597 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1598 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1600 [ID-PMIP6-IPv4] 1601 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1602 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-10 1603 (work in progress), March 2009. 1605 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1606 "Multiple Care-of Addresses Registration", 1607 draft-ietf-monami6-multiplecoa-12 (work in progress), 1608 March 2009. 1610 [ID-DSMIP6] 1611 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1612 Routers", draft-ietf-mext-nemo-v4traversal-09 (work in 1613 progress), February 2009. 1615 16.2. Informative References 1617 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1618 August 2002. 1620 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1621 Mobile IPv4", RFC 3543, August 2003. 1623 Authors' Addresses 1625 Ahmad Muhanna 1626 Nortel 1627 2221 Lakeside Blvd. 1628 Richardson, TX 75082 1629 USA 1631 Email: amuhanna@nortel.com 1632 Mohamed Khalil 1633 Nortel 1634 2221 Lakeside Blvd. 1635 Richardson, TX 75082 1636 USA 1638 Email: mkhalil@nortel.com 1640 Sri Gundavelli 1641 Cisco Systems 1642 170 West Tasman Drive 1643 San Jose, CA 95134 1644 USA 1646 Email: sgundave@cisco.com 1648 Kuntal Chowdhury 1649 Starent Networks 1650 30 International Place 1651 Tewksbury, MA 01876 1652 USA 1654 Email: kchowdhury@starentnetworks.com 1656 Parviz Yegani 1657 Juniper Networks 1658 1194 North Mathilda Avenue 1659 Sunnyvale, CA 94089 1660 USA 1662 Email: pyegani@juniper.net