idnits 2.17.1 draft-ietf-mext-binding-revocation-02.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 1464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1488. 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 -- 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 (November 25, 2008) is 5603 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-06 == Outdated reference: A later version (-14) exists of draft-ietf-monami6-multiplecoa-10 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-05 ** 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 (~~), 4 warnings (==), 8 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: May 29, 2009 S. Gundavelli 6 Cisco Systems 7 K. Chowdhury 8 Starent Networks 9 P. Yegani 10 Juniper Networks 11 November 25, 2008 13 Binding Revocation for IPv6 Mobility 14 draft-ietf-mext-binding-revocation-02.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 May 29, 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 . . 9 70 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings . . 10 71 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. Exchanging Binding Revocation Messages over an IPv4 73 Transport Network . . . . . . . . . . . . . . . . . . . . . . 10 74 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10 75 6.1. Binding Revocation Indication Message . . . . . . . . . . 12 76 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14 77 7. Binding Revocation Process Considerations . . . . . . . . . . 16 78 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 16 79 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 17 80 7.3. Retransmission of Binding Revocation Indication . . . . . 18 81 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 18 82 8.1. Sending Binding Revocation Indication . . . . . . . . . . 18 83 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20 84 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 20 85 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 20 86 9.1.1. Sending Binding Revocation Indication . . . . . . . . 20 87 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23 88 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 23 89 9.2.1. Receiving Binding Revocation Indication . . . . . . . 23 90 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 24 91 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 25 92 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 25 93 10.1.1. Receiving Binding Revocation Indication . . . . . . . 25 94 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 27 95 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 27 96 10.2.1. Sending Binding Revocation Indication . . . . . . . . 28 97 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 28 98 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 29 99 11.1. Receiving Binding Revocation Indication . . . . . . . . . 29 100 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 30 101 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 31 102 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 103 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 104 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 105 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 106 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 107 16.2. Informative References . . . . . . . . . . . . . . . . . . 32 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 109 Intellectual Property and Copyright Statements . . . . . . . . . . 34 111 1. Introduction 113 In the case of Mobile IPv6 and for administrative reason, sometimes 114 it becomes necessary to inform the mobile node that its registration 115 has been revoked and the mobile node is no longer able to receive IP 116 mobility service using its Home Address. In some networks where 117 Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 118 registration revocation mechanism has been specified [RFC3543]. 120 This document defines the semantics of the revocation mechanism of a 121 mobile node registration binding, which could have been established 122 using a Client Mobile IPv6 or any of its extensions, e.g. Proxy 123 Mobile IPv6 signaling. The proposed revocation mechanism uses a new 124 MH type for revocation signaling which is applicable to 125 Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used 126 by any two IP mobility entities. As an example, this mechanism 127 allows a local mobility anchor, involved in providing IP mobility 128 services to a mobile node, to notify the mobile access gateway of the 129 termination of a mobile node binding registration. In another 130 example, a mobile access gateway can use this mechanism to notify its 131 local mobility anchor peer with a bulk termination of all or a subset 132 of Proxy Mobile IPv6 bindings that are registered with the local 133 mobility anchor and currently being served by the mobile access 134 gateway. 136 2. Conventions & Terminology 138 2.1. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2.2. Terminology 146 All the general mobility related terminology and abbreviations are to 147 be interpreted as defined in Mobile IPv6 specification [RFC3775] and 148 Proxy Mobile IPv6 specification [RFC5213]. 150 3. Binding Revocation Protocol and Use Cases Overview 152 This specification defines a binding revocation mechanism 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 binding. 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 of 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 [RFC5213], the revocation 180 procedure can be initiated by the local mobility anchor by sending a 181 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 [RFC5213] and the MN-ID option [RFC4283] to indicate to 185 the mobility access gateway the identity of the PMIPv6 binding that 186 needs to be terminated. When the mobility access gateway receives 187 the BRI message with the (A) bit set, the mobility access gateway 188 responds to the local mobility anchor by sending a BRA message. 190 On the other hand, the MAG usually sends a de-registration message by 191 sending a Proxy BU with a lifetime of zero to indicate to the LMA of 192 the termination of the PMIPv6 mobile node binding registration. In 193 this case, the MAG includes the MN HNP option, the MN-ID option and 194 all other required mobility options as per [RFC5213] in order for the 195 LMA to identify the mobile node PMIPv6 binding. However, in the case 196 when the mobility access gateway communicates a bulk termination of 197 PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A) 198 bits are set and includes the MAG identity in the MN-ID option. When 199 the LMA receives such BRI message, it ensures that the mobility 200 access gateway is authorized to send such bulk termination message 201 and then process the BRI message accordingly. If the local mobility 202 anchor processes the BRI message successfully and since the (A) bit 203 is set, the LMA responds to the mobile access gateway by sending the 204 BRA message. Additionally, the initiator of the binding revocation 205 procedure includes an indication in the Revocation Trigger field to 206 indicate to the receiving node the cause for the revocation 207 procedure. 209 3.2. Client MIPv6 and DSMIP6 Use Case 211 Binding revocation mechanism is applicable to Client Mobile IPv6 and 212 DSMIPv6 session(s) when the home agent needs to inform the mobile 213 node that its binding registration has been revoked, e.g. for an 214 administrative reason. This mechanism enables the home domain to 215 dynamically allow the user to act upon the revocation message in 216 order to not have an unexpectedly interrupted mobile IPv6 services. 218 In this case, the home agent sends a BRI message to indicate to the 219 mobile node that its current mobile IPv6 binding has been revoked and 220 it no longer can receive IP mobility service. The home agent 221 includes the mobile node home address in Type 2 header as used in 222 [RFC3775] and sets the Revocation Trigger field to a proper value, 223 e.g. Administrative Reason. In the case of DSMIPv6 session, the 224 home agent may additionally include the mobile node assigned IPv4 225 Home Address Option. When the mobile node receives the BRI message, 226 it sends a BRA message as described in Section 11.2 to the home 227 agent. Figure 1 illustrates the message sequencing when home agent 228 revokes a mobile node binding registration. 230 MN HA 231 | | 232 | HoA in Type 2 Hdr + BRI [seq.#, A bit] | 233 |<------------------------------------------| 234 | | 235 | | 236 | | 237 | HoA in Destination Option BRA[seq.#] | 238 |------------------------------------------>| 239 | | 240 | | 242 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 244 3.3. Multi-Care of Addresses (Monami6) Use Case 246 In the case of Monami6 protocol, a mobile node is able to register 247 multiple care-of addresses for the same home address [ID-MCoA]. 248 Binding revocation mechanism is applicable to Monami6 when the HA 249 sends a BRI message to revoke a single or more care-of address 250 bindings. 252 3.3.1. Termination of Multiple Care-of Addresses Bindings 254 In the case of multiple care-of addresses, the home agent maintains 255 different binding for each pair of care-of address and home address. 256 These bindings are also indexed and identified during the mobile node 257 registration using a Binding ID mobility option [ID-MCoA]. In this 258 case, the HA may revoke any binding, more than one binding, or all of 259 the bindings for the same mobile node home address. 261 In the case when home agent revokes a single binding for a mobile 262 node with multiple care-of addresses registration, the home agent 263 sends a BRI message to the mobile node with the corresponding BID 264 option included and the HoA is in the Type 2 header. If the home 265 agent needs to revoke more than one of the mobile node registered 266 care-of addresses, the home agent includes all the corresponding 267 Binding ID options which reference these care-of addresses in the 268 same BRI message. Figure 2 illustrates the message flow when the HA 269 revokes two registered Care-of addresses for the same MN in a single 270 BRI message. The home agent can revoke any registered binding(s) by 271 sending a BRI message to the respective mobile node. 273 HA Binding Cache 274 ================ 275 MN-BID1 [CoA1+HoA] 276 MN HA MN-BID2 [CoA2+HoA] 277 | | MN-BID3 [CoA3+HoA] 278 | BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA] 279 |<------------------------------------------| 280 | | 281 | | 282 | | 283 | BRA [seq.#, Status] | 284 |------------------------------------------>| 285 | | 286 | | 288 Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings 290 3.3.2. Termination of All Care-of Addresses Bindings 292 The home agent may revoke all of the mobile node registered bindings, 293 by sending a BRI message without including any BID options while the 294 HoA is included in the Type 2 header. Figure 1 illustrates the 295 message flow when the home agent revokes all registered Care-of 296 addresses bindings for a MN in a single BRI message. 298 3.4. Proxy MIPv6 Use Case 300 Since the Mobile node does not participate in the mobility mechanism 301 in the case of PMIPv6, there are many scenarios where Binding 302 Revocation mechanism is needed to clean resources and make sure that 303 the mobility entities, e.g. MAG and LMA, are always synchronized 304 with respect to the status of the existing proxy mobile IPv6 305 bindings. The binding revocation mechanism is generic enough that 306 can be used in all applicable PMIPv6 scenarios and deployment 307 options. For example, this revocation mechanism is still applicable 308 and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports 309 and when the mobile node uses IPv4 or IPv6 address as specified in 310 [ID-PMIP6-IPv4]. 312 When the MAG receives a BRI message as in Section 10.1.1, the MAG 313 sends a BRA message to the LMA following the rules describes in 314 Section 10.1.2. Similarly if the LMA receives a BRI message with the 315 (A) bit is set, the LMA responds to the MAG by sending a BRA message. 317 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding 319 The local mobility anchor may send a BRI message to the mobile access 320 gateway, hosting a specific proxy mobile IPv6 binding, with the 321 appropriate value in the revocation trigger field to indicate that 322 the mobile node binding has been terminated and the MAG can clean up 323 the applicable resources. When the MAG receives a BRI message, the 324 MAG identify the respected binding and if the (A) bit was set in the 325 received BRI message, the MAG sends a BRA message to the LMA. In 326 this case, the MAG could send a Router Advertisement message to the 327 MN with the home network prefix lifetime is set to zero. 329 As an example, Figure 3, illustrates the message sequence for 330 revoking a mobile node binding at the source MAG during the MN inter- 331 MAG handoff. During the inter-MAG handoff, the mobile node moves 332 from the source MAG to the target MAG. The target MAG sends a PBU 333 with the new care-of-address to the LMA to update the mobile node 334 point of attachment. Since the MN binding at the LMA points to the 335 source MAG and upon receiving the PBU from the target MAG, LMA 336 updates the MN BCE and send a PBA to the target MAG. LMA can send a 337 BRI message with the appropriate revocation trigger value, e.g. 338 inter-MAG handoff - same Access Types, to the source MAG in order to 339 clean up the applicable resources reserved for the specified MN 340 binding. The MAG acknowledges the BRI message by sending a BRA 341 message to indicate the success or failure of the termination of the 342 mobile node binding. 344 The process identified above can also be used by the LMA in scenarios 345 other than the inter-MAG handoff with the proper revocation trigger 346 value to indicate to the peer MAG that a specific proxy mobile IPv6 347 binding or bindings have been revoked. 349 sMAG tMAG LMA 350 | | | 351 | | PBU | 352 | |--------------------------->| 353 | | PBU triggers 354 | | BRI Msg to sMAG 355 | | | 356 | | PBA | 357 | |<---------------------------| 358 | | | 359 | | | 360 | BRI [seq.#, R. Trigger, P, A bits, NAI] | 361 |<-----------------------------------------| 362 | | | 363 | | | 364 | | | 365 | | | 366 | BRA [seq.#, Status, P bit] | 367 |----------------------------------------->| 368 | | | 369 | | | 371 Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff 373 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings 375 The LMA sends a BRI message to indicate that all bindings which are 376 hosted by the peer MAG and registered with the LMA are being revoked 377 by setting the (G) bit as described in Section 9.1.1. 379 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings 381 The mobile access gateway sends a BRI message with the (G) bit is set 382 to indicate that all mobility bindings which are registered at the 383 LMA and attached to the MAG are being revoked as in Section 10.2.1. 384 When the LMA receives a BRI message with the (G) bit is set from a 385 specified MAG, the LMA checks if the MAG is authorized to use global 386 revocations and responds with the appropriate status code by sending 387 a BRA message as in Section 9.2.2. 389 4. Security Model 391 The binding revocation protocol described here uses the same security 392 association between the MN and the HA or the MAG and the LMA that has 393 been used to exchange the corresponding Client MIPv6 or Proxy MIPv6 394 BU and BA when the mobile node binding was created. If IPsec is 395 used, the SPD of the respected IPsec SA MUST allow the Binding 396 Revocation Signaling MH type in order to allow BRI and BRA 397 messages to be exchanged. 399 Additionally, in the case when the LMA receives a BRI which indicates 400 a bulk termination, i.e., the (G) bit is set, the LMA MUST verify 401 that the MAG sending the binding revocation indication message is 402 authorized to invoke Global revocation. 404 5. Exchanging Binding Revocation Messages over an IPv4 Transport 405 Network 407 In some deployments, the network between the MAG and the LMA may only 408 support IPv4 transport. In this case, the Binding Revocation 409 messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding 410 Update and Proxy Binding Acknowledgment messages are sent using UDP 411 encapsulation to traverse NATs, then the Binding Revocation messages 412 are sent using the same UDP encapsulation. The same UDP port that 413 was used for the Proxy Binding Update and Proxy Binding 414 Acknowledgement messages will also be used when transporting Binding 415 Revocation messages over IPv4 using UDP encapsulation. For more 416 details on tunneling Proxy Mobile IPv6 signaling messages over IPv4, 417 see [ID-PMIP6-IPv4]. 419 6. Binding Revocation Message 421 This section defines a Binding Revocation Message that use a MH type 422 with a Binding Revocation type field that follow the MH 423 format described in section 6.1. [RFC3775]. The value in the 424 Binding Revocation Type field as shown in Figure 4 defines the type 425 of the Binding Revocation message, (BRI or BRA). If the Binding 426 Revocation type field is set to 1, the Binding Revocation Message is 427 a Binding Revocation Indication message as in Section 6.1. However, 428 when the Binding Revocation type field is set to a value 2, the 429 Binding Revocation Message is a Binding Revocation Acknowledgement 430 message as in Section 6.2. 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 | Payload Proto | Header Len | MH Type | Reserved | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Checksum | B.R. Type | | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 439 | | 440 . Binding Revocation Message Data . 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 4: Binding Revocation Message 446 Binding Revocation Type 448 8-bit unsigned integer. It defines the type of Binding Revocation 449 Message. It can be assigned one of the following values: 451 0 Reserved. 452 1 Binding Revocation Indication Message. 453 2 Binding Revocation Acknowledgement Message. 454 All other values are reserved. 456 Binding Revocation Message Data 458 The Binding Revocation Message Data follows the Binding Revocation 459 Message format that is defined in this document for the specified 460 value in the Binding Revocation Type field. It is either a BRI as 461 in Section 6.1 or BRA as in Section 6.2. 463 6.1. Binding Revocation Indication Message 465 The Binding Revocation Indication (BRI) message is a Binding 466 Revocation Message which has a MH type and a Binding 467 Revocation Type value of 1. It is used by the revoking mobility node 468 to inform the receiving mobility entity that the IP mobility service 469 of a specific binding or bindings have been revoked. Binding 470 Revocation Indication message is sent as described in Section 8.1, 471 Section 9.1.1, and Section 10.2.1. 473 When the value 1 is indicated in the B. R. type field of the Binding 474 Revocation Message, the format of the Binding Revocation Message Data 475 follows the Binding Revocation Indication message as in Figure 5 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | B.R. Type = 1 | R. Trigger | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Sequence # |P|A|G| Reserved | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 . . 486 . Mobility options . 487 | | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 5: Binding Revocation Indication Message 492 Revocation Trigger 494 8-bit unsigned integer indicting the event which triggered the 495 revoking node to send the BRI message. The following Revocation 496 Trigger values are currently defined: 498 0 Reserved. 499 1 Unspecified. 500 2 Administrative Reason. 501 3 Inter-MAG Handoff - same Access Types. 503 4 Inter-MAG Handoff - different Access Types. 504 5 Inter-MAG - Unknown Handoff. 505 6 Per-Peer Policy. 506 7 Revoking Node Local Policy. 507 8 User Initiated Session(s) Termination. 508 9 Access Network Session(s) Termination. 509 10 IPv4 HoA Binding ONLY. 510 11 Possible Out-of Sync BCE State. 511 250-255 Reserved For Testing Purposes only. 512 All other values are Reserved. 514 Sequence # 516 A 16-bit unsigned integer used by the sending mobility node to 517 match a returned Binding Revocation Acknowledgement with this 518 Binding Revocation Indication. 520 Proxy Binding (P) 522 The Proxy Binding (P) bit is set by the sending mobility node to 523 indicate that the revoked binding(s) is a proxy MIPv6 binding. 525 Acknowledge (A) 527 The Acknowledge (A) bit is set by the sending mobility node, e.g. 528 LMA, HA, or MAG, to request a Binding Revocation Acknowledgement 529 be returned upon receipt of the Binding Revocation Indication as 530 in Section 8.1, Section 9.1.1, and Section 10.2.1. 532 Global (G) 534 The Global (G) bit is set by the sending mobility node, LMA or 535 MAG, to request the termination of all Per-Peer mobility Bindings 536 or Multiple Bindings which share a common identifier that are 537 served by the sending and receiving mobility entities as in 538 Section 9.1.1 and Section 10.2.1. 540 Reserved 542 These fields are unused. They MUST be initialized to zero by the 543 sender and MUST be ignored by the receiver. 545 Mobility Options 547 Variable-length field of such length that the complete Mobility 548 Header is an integer multiple of 8 octets long. This field 549 contains zero or more TLV-encoded mobility options. This document 550 does not define any new mobility option. The receiver MUST ignore 551 and skip any options which it does not understand. These mobility 552 option(s) are used by the receiving mobility entity to identify 553 the specific binding or bindings that the sending mobility entity 554 requesting to be revoked. 556 The following options are valid in a Binding Revocation Indication: 558 o Home Network Prefix option [RFC5213]. This option MAY be used 559 when the (P) bit is set. This option MUST be present when the BRI 560 is used to revoke a single PMIP binding cache entry. 562 o Mobile Node Identifier Option [RFC4283]. This option is mandatory 563 when the (P) bit is set. Additionally, If the (G) bit is set by 564 the mobile access gateway, this option carries the MAG identity. 566 o Binding ID mobility option [ID-MCoA]. This option is mandatory if 567 the sending mobility entity request to terminate one binding of a 568 multi care-of addresses bindings for the same mobile node. The 569 sending mobility entity may include more than one of the Binding 570 ID mobility options. 572 o IPv4 Home Address option which contains the mobile node home IPv4 573 address [ID-DSMIP6]. 575 If no options are present in this message, 4 octets of padding are 576 necessary and the Header Len field of the Binding Revocation Message 577 will be set to 1. 579 6.2. Binding Revocation Acknowledgement Message 581 The Binding Revocation Acknowledgement (BRA) message is a Binding 582 Revocation Message which has a MH type and a Binding 583 Revocation Type value of 2. It is used to acknowledge the receipt of 584 a Binding Revocation Indication message described in Section 6.1. 585 This packet is sent as described in Section 9.2.2, Section 10.1.2, 586 and Section 11.2. 588 When the value 2 is indicated in the Binding Revocation type field of 589 the Binding Revocation Message, the format of the Binding Revocation 590 Message Data follows the Binding Revocation Acknowledgement message 591 as in Figure 6 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | B.R. Type = 2 | Status | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Sequence # |P|G| Reserved | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | | 600 . . 601 . Mobility options . 602 . . 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Figure 6: Binding Revocation Acknowledgement Message 608 Status 610 8-bit unsigned integer indicating the result of processing the 611 Binding Revocation Indication message by the receiving mobility 612 entity. The following status values are currently defined. 614 0 success. 615 1 partial success. 616 2 Binding Does NOT Exist. 617 3 IPv4 HoA Binding Does NOT Exist. 618 4 Global Revocation NOT Authorized. 619 5 CAN NOT Identify Binding. 620 6 Revocation Failed, MN is Attached. 622 Sequence # 624 The sequence number in the Binding Revocation Acknowledgement is 625 copied from the Sequence Number field in the Binding Revocation 626 Indication. It is used by the revoking mobility entity, e.g. HA, 627 LMA, in matching this Binding Revocation Acknowledgement with the 628 outstanding BRI. 630 Proxy Binding (P) 632 The Proxy Binding (P) bit is set if the (P) bit is set in the 633 corresponding Binding Revocation Indication message. 635 Global (G) 637 The Global (G) bit is set if the (G) bit is set in the 638 corresponding BRI message. Section 9.2.2 and Section 10.1.2. 640 Reserved 642 These fields are unused. They MUST be initialized to zero by the 643 sender and MUST be ignored by the receiver. 645 Mobility Options 647 Variable-length field of such length that the complete Mobility 648 Header is an integer multiple of 8 octets long. This field 649 contains zero or more TLV-encoded mobility options. In the case 650 when the Status field is set to success, no mobility option is 651 required. The mobility option(s) is usually used to communicate 652 information of the bindings that failed the revocation procedure. 654 The following options are valid in a Binding Revocation 655 Acknowledgement: 657 o Home Network Prefix option [RFC5213]. This option MAY be included 658 when the (P) bit is set. 660 o Mobile Node Identifier Option [RFC4283]. This option MAY be 661 included when the (P) bit is set. This option SHOULD be included 662 if the Home Network Prefix option is included. 664 o Binding ID mobility option [ID-MCoA]. This option MAY be included 665 to indicate the specific Binding ID that the receiving node failed 666 to revoke. 668 If no options are present in this message, 4 octets of padding are 669 necessary and the Header Len field of the Binding Revocation Message 670 will be set to 1. 672 7. Binding Revocation Process Considerations 674 The following subsections describe the details of the binding 675 revocation generic process by the different mobility entities. 677 7.1. Sending Binding Revocation Messages 679 When sending a Binding Revocation message, the sending mobility node, 680 initiator, follows the rules of constructing a Mobility Header as in 681 Section 9.2 of [RFC3775] with the exception of setting the MH Type 682 field to . The new Mobility Header 1345 type value needs to be assigned from the same numbering space as 1346 allocated for the other Mobility Header types. 1348 14. Security Considerations 1350 The protocol described here uses the same security association 1351 between the MN and the HA or the MAG and the LMA that has been used 1352 to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the 1353 session was established. If IPsec is used, The SPD of this IPsec SA 1354 MUST allow the MH type for the Binding Revocation Message defined in 1355 this document. 1357 However, in the case when the MAG sends a BRI message with the Global 1358 (G) bit is set, the LMA MUST verify that the MAG is authorized to use 1359 Per-Peer Global Revocation. 1361 15. Acknowledgements 1363 The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- 1364 Cazavet, Domagoj Premec for their review and comments of this draft 1365 and all colleagues who have supported the advancement of this draft 1366 effort. 1368 16. References 1370 16.1. Normative References 1372 [ID-DSMIP6] 1373 Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1374 Routers", draft-ietf-mext-nemo-v4traversal-06 (work in 1375 progress), November 2008. 1377 [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, 1378 "Multiple Care-of Addresses Registration", 1379 draft-ietf-monami6-multiplecoa-10 (work in progress), 1380 November 2008. 1382 [ID-PMIP6-IPv4] 1383 Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1384 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 1385 (work in progress), September 2008. 1387 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1388 Requirement Levels", BCP 14, RFC 2119, March 1997. 1390 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1391 in IPv6", RFC 3775, June 2004. 1393 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1394 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1395 (MIPv6)", RFC 4283, November 2005. 1397 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1398 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1400 16.2. Informative References 1402 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1403 August 2002. 1405 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1406 Mobile IPv4", RFC 3543, August 2003. 1408 Authors' Addresses 1410 Ahmad Muhanna 1411 Nortel 1412 2221 Lakeside Blvd. 1413 Richardson, TX 75082 1414 USA 1416 Email: amuhanna@nortel.com 1418 Mohamed Khalil 1419 Nortel 1420 2221 Lakeside Blvd. 1421 Richardson, TX 75082 1422 USA 1424 Email: mkhalil@nortel.com 1426 Sri Gundavelli 1427 Cisco Systems 1428 170 West Tasman Drive 1429 San Jose, CA 95134 1430 USA 1432 Email: sgundave@cisco.com 1434 Kuntal Chowdhury 1435 Starent Networks 1436 30 International Place 1437 Tewksbury, MA 01876 1438 USA 1440 Email: kchowdhury@starentnetworks.com 1442 Parviz Yegani 1443 Juniper Networks 1444 1194 North Mathilda Avenue 1445 Sunnyvale, CA 94089 1446 USA 1448 Email: pyegani@juniper.net 1450 Full Copyright Statement 1452 Copyright (C) The IETF Trust (2008). 1454 This document is subject to the rights, licenses and restrictions 1455 contained in BCP 78, and except as set forth therein, the authors 1456 retain all their rights. 1458 This document and the information contained herein are provided on an 1459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1461 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1462 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1463 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1466 Intellectual Property 1468 The IETF takes no position regarding the validity or scope of any 1469 Intellectual Property Rights or other rights that might be claimed to 1470 pertain to the implementation or use of the technology described in 1471 this document or the extent to which any license under such rights 1472 might or might not be available; nor does it represent that it has 1473 made any independent effort to identify any such rights. Information 1474 on the procedures with respect to rights in RFC documents can be 1475 found in BCP 78 and BCP 79. 1477 Copies of IPR disclosures made to the IETF Secretariat and any 1478 assurances of licenses to be made available, or the result of an 1479 attempt made to obtain a general license or permission for the use of 1480 such proprietary rights by implementers or users of this 1481 specification can be obtained from the IETF on-line IPR repository at 1482 http://www.ietf.org/ipr. 1484 The IETF invites any interested party to bring to its attention any 1485 copyrights, patents or patent applications, or other proprietary 1486 rights that may cover technology that may be required to implement 1487 this standard. Please address the information to the IETF at 1488 ietf-ipr@ietf.org. 1490 Acknowledgment 1492 Funding for the RFC Editor function is provided by the IETF 1493 Administrative Support Activity (IASA).