Network Working Group A. Muhanna Internet-Draft M. Khalil Intended status: Standards Track Nortel Expires: March 1, 2009 S. Gundavelli Cisco Systems K. Chowdhury Starent Networks P. Yegani Cisco Systems August 28, 2008 Binding Revocation for IPv6 Mobility draft-ietf-mext-binding-revocation-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 1, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines the revocation semantics for terminating a mobile node's mobility session and associated resources. These Muhanna, et al. Expires March 1, 2009 [Page 1] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 semantics are generic enough and can be used by mobility entities in the case of Client Mobile IPv6 and its extensions. This mechanism allows the mobility entity which initiates the revocation procedure to request its corresponding one to terminate either one, multiple or all specified binding cache entries. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2.1. Conventions used in this document . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 3.2. Client MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . 6 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 3.3.1. Termination of Multiple Care-of Addresses Bindings . . 7 3.3.2. Termination of All Care-of Addresses Bindings . . . . 8 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 9 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings . . 10 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Exchanging Binding Revocation Messages over an IPv4 Transport Network . . . . . . . . . . . . . . . . . . . . . . 10 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10 6.1. Binding Revocation Indication Message . . . . . . . . . . 12 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14 7. Binding Revocation Process Considerations . . . . . . . . . . 16 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 16 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 17 7.3. Retransmission of Binding Revocation Indication . . . . . 18 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 18 8.1. Sending Binding Revocation Indication . . . . . . . . . . 18 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 20 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 20 9.1.1. Sending Binding Revocation Indication . . . . . . . . 20 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 23 9.2.1. Receiving Binding Revocation Indication . . . . . . . 23 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 24 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 25 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 25 10.1.1. Receiving Binding Revocation Indication . . . . . . . 25 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 27 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 27 Muhanna, et al. Expires March 1, 2009 [Page 2] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 10.2.1. Sending Binding Revocation Indication . . . . . . . . 27 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 28 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 29 11.1. Receiving Binding Revocation Indication . . . . . . . . . 29 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 30 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 30 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 34 Muhanna, et al. Expires March 1, 2009 [Page 3] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 1. Introduction In the case of Mobile IPv6 and for administrative reason, sometimes it becomes necessary to inform the mobile node that its registration has been revoked and the mobile node is no longer able to receive IP mobility service using its Home Address. In some networks where Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 registration revocation mechanism has been specified [RFC3543]. This document defines the semantics of the revocation mechanism of a mobile node registration binding, which could have been established using a Client Mobile IPv6 or any of its extensions, e.g. Proxy Mobile IPv6 signaling. The proposed revocation mechanism uses a new MH type for revocation signaling which is applicable to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any two IP mobility entities. As an example, this mechanism allows a local mobility anchor, involved in providing IP mobility services to a mobile node, to notify the mobile access gateway of the termination of a mobile node binding registration. In another example, a mobile access gateway can use this mechanism to notify its local mobility anchor peer with a bulk termination of all or a subset of Proxy Mobile IPv6 bindings that are registered with the local mobility anchor and currently being served by the mobile access gateway. 2. Conventions & Terminology 2.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Terminology All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 specification [RFC3775] and Proxy Mobile IPv6 specification [RFC5213]. 3. Binding Revocation Protocol and Use Cases Overview This specification defines a binding revocation mechanism where a mobility node can communicate to the mobile node or another mobility node the termination of the mobile node registration binding. The following subsections describe the protocol overview and applicable use cases. Muhanna, et al. Expires March 1, 2009 [Page 4] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 3.1. Binding Revocation Protocol In the case of Client Mobile IPv6, the revocation procedure can be initiated by the home agent. If the home network decides to terminate the service of the mobile node, the home agent sends a Binding Revocation Indication (BRI) message to the mobile node. The home agent includes the HoA option as specified in [RFC3775] to indicate the impacted mobile node binding. When the mobile node receives a BRI message with its HoA included and the Acknowledge (A) bit is set, the mobile node responds by sending a Binding Revocation Acknowledgement (BRA) message. In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also be initiated by the home agent. If the home network decides to terminate the service of the mobile node, the home agent sends a BRI message to the mobile node to indicate the termination of the mobile node IP Mobility service. The home agent may include the HoA option with the mobile node assigned home IPv4 address. After receiving the BRI message with the Acknowledge (A) bit is set, the mobile node responds by sending a BRA message. Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation procedure can be initiated by the local mobility anchor by sending a BRI message to communicate the termination of a mobile node registration binding to the mobility access gateway. In this case, the local mobility anchor includes the mobile node Home Network Prefix option [RFC5213] and the MN-ID option [RFC4283] to indicate to the mobility access gateway the identity of the PMIPv6 binding that needs to be terminated. When the mobility access gateway receives the BRI message with the (A) bit set, the mobility access gateway responds to the local mobility anchor by sending a BRA message. On the other hand, the MAG usually sends a de-registration message by sending a Proxy BU with a lifetime of zero to indicate to the LMA of the termination of the PMIPv6 mobile node binding registration. In this case, the MAG includes the MN HNP option, the MN-ID option and all other required mobility options as per [RFC5213] in order for the LMA to identify the mobile node PMIPv6 binding. However, in the case when the mobility access gateway communicates a bulk termination of PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A) bits are set and includes the MAG identity in the MN-ID option. When the LMA receives such BRI message, it ensures that the mobility access gateway is authorized to send such bulk termination message and then process the BRI message accordingly. If the local mobility anchor processes the BRI message successfully and since the (A) bit is set, the LMA responds to the mobile access gateway by sending the BRA message. Additionally, the initiator of the binding revocation procedure includes an indication in the Revocation Trigger field to Muhanna, et al. Expires March 1, 2009 [Page 5] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 indicate to the receiving node the cause for the revocation procedure. 3.2. Client MIPv6 and DSMIP6 Use Case Binding revocation mechanism is applicable to Client Mobile IPv6 and DSMIPv6 session(s) when the home agent needs to inform the mobile node that its binding registration has been revoked, e.g. for an administrative reason. This mechanism enables the home domain to dynamically allow the user to act upon the revocation message in order to not have an unexpectedly interrupted mobile IPv6 services. In this case, the home agent sends a BRI message to indicate to the mobile node that its current mobile IPv6 binding has been revoked and it no longer can receive IP mobility service. The home agent includes the mobile node home address in HoA option in the destination option header as used in [RFC3775] and sets the Revocation Trigger field to a proper value, e.g. Administrative Reason. In the case of DSMIPv6 session, the home agent may additionally include the mobile node assigned IPv4 Home Address Option. When the mobile node receives the BRI message, it sends a BRA message as described in Section 11.2 to the home agent. Figure 1 illustrates the message sequencing when home agent revokes a mobile node binding registration. MN HA | | | HoA in Dest. Opt. Hdr + BRI[seq.#, A bit] | |<------------------------------------------| | | | | | | | BRA[seq.#] | |------------------------------------------>| | | | | Figure 1: Home Agent Revokes a Mobile Node Binding Registration Muhanna, et al. Expires March 1, 2009 [Page 6] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 3.3. Multi-Care of Addresses (Monami6) Use Case In the case of Monami6 protocol, a mobile node is able to register multiple care-of addresses for the same home address [ID-MCoA]. Binding revocation mechanism is applicable to Monami6 when the HA sends a BRI message to revoke a single or more care-of address bindings. 3.3.1. Termination of Multiple Care-of Addresses Bindings In the case of multiple care-of addresses, the home agent maintains different binding for each pair of care-of address and home address. These bindings are also indexed and identified during the mobile node registration using a Binding ID mobility option [ID-MCoA]. In this case, the HA may revoke any binding, more than one binding, or all of the bindings for the same mobile node home address. In the case when home agent revokes a single binding for a mobile node with multiple care-of addresses registration, the home agent sends a BRI message to the mobile node with the corresponding BID option included and the HoA option in the destination option header. If the home agent needs to revoke more than one of the mobile node registered care-of addresses, the home agent includes all the corresponding BID options which reference these care-of addresses in the same BRI message. Figure 2 illustrates the message flow when the HA revokes two registered Care-of addresses for the same MN in a single BRI message. The home agent can revoke any registered binding(s) by sending a BRI message to the respective mobile node. HA Binding Cache ================ MN-BID1 [CoA1+HoA] MN HA MN-BID2 [CoA2+HoA] | | MN-BID3 [CoA3+HoA] | BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA] |<------------------------------------------| | | | | | | | BRA [seq.#, Cause] | |------------------------------------------>| | | | | Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings Muhanna, et al. Expires March 1, 2009 [Page 7] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 3.3.2. Termination of All Care-of Addresses Bindings The home agent may revoke all of the mobile node registered bindings, by sending a BRI message without including any BID options while the HoA option is included in the destination options header. Figure 1 illustrates the message flow when the home agent revokes all registered Care-of addresses bindings for a MN in a single BRI message. 3.4. Proxy MIPv6 Use Case Since the Mobile node does not participate in the mobility mechanism in the case of PMIPv6, there are many scenarios where Binding Revocation mechanism is needed to clean resources and make sure that the mobility entities, e.g. MAG and LMA, are always synchronized with respect to the status of the existing proxy mobile IPv6 bindings. The binding revocation mechanism is generic enough that can be used in all applicable PMIPv6 scenarios and deployment options. For example, this revocation mechanism is still applicable and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports and when the mobile node uses IPv4 or IPv6 address as specified in [ID-PMIP6-IPv4]. When the MAG receives a BRI message as in Section 10.1.1, the MAG sends a BRA message to the LMA following the rules describes in Section 10.1.2. Similarly if the LMA receives a BRI message with the (A) bit is set, the LMA responds to the MAG by sending a BRA message. 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding The local mobility anchor may send a BRI message to the mobile access gateway, hosting a specific proxy mobile IPv6 binding, with the appropriate value in the revocation trigger field to indicate that the mobile node binding has been terminated and the MAG can clean up the applicable resources. When the MAG receives a BRI message, the MAG identify the respected binding and if the (A) bit was set in the received BRI message, the MAG sends a BRA message to the LMA. In this case, the MAG could send a Router Advertisement message to the MN with the home network prefix lifetime is set to zero. As an example, Figure 3, illustrates the message sequence for revoking a mobile node binding at the source MAG during the MN inter- MAG handoff. During the inter-MAG handoff, the mobile node moves from the source MAG to the target MAG. The target MAG sends a PBU with the new care-of-address to the LMA to update the mobile node Muhanna, et al. Expires March 1, 2009 [Page 8] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 point of attachment. Since the MN binding at the LMA points to the source MAG and upon receiving the PBU from the target MAG, LMA updates the MN BCE and send a PBA to the target MAG. LMA can send a BRI message with the appropriate revocation trigger value, e.g. inter-MAG handoff - same Access Types, to the source MAG in order to clean up the applicable resources reserved for the specified MN binding. The MAG acknowledges the BRI message by sending a BRA message to indicate the success or failure of the termination of the mobile node binding. The process identified above can also be used by the LMA in scenarios other than the inter-MAG handoff with the proper revocation trigger value to indicate to the peer MAG that a specific proxy mobile IPv6 binding or bindings have been revoked. sMAG tMAG LMA | | | | | PBU | | |--------------------------->| | | PBU triggers | | BRI Msg to sMAG | | | | | PBA | | |<---------------------------| | | | | | | | BRI [seq.#, R. Trigger, P, A bits, NAI] | |<-----------------------------------------| | | | | | | | | | | | | | BRA [seq.#, Cause, P bit] | |----------------------------------------->| | | | | | | Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings The LMA sends a BRI message to indicate that all bindings which are hosted by the peer MAG and registered with the LMA are being revoked by setting the (G) bit as described in Section 9.1.1. Muhanna, et al. Expires March 1, 2009 [Page 9] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings The mobile access gateway sends a BRI message with the (G) bit is set to indicate that all mobility bindings which are registered at the LMA and attached to the MAG are being revoked as in Section 10.2.1. When the LMA receives a BRI message with the (G) bit is set from a specified MAG, the LMA checks if the MAG is authorized to use global revocations and responds with the appropriate status code by sending a BRA message as in Section 9.2.2. 4. Security Model The binding revocation protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding Client MIPv6 or Proxy MIPv6 BU and BA when the mobile node binding was created. If IPsec is used, the SPD of the respected IPsec SA MUST allow the Binding Revocation Signaling MH type in order to allow BRI and BRA messages to be exchanged. Additionally, in the case when the LMA receives a BRI which indicates a bulk termination, i.e., the (G) bit is set, the LMA MUST verify that the MAG sending the binding revocation indication message is authorized to invoke Global revocation. 5. Exchanging Binding Revocation Messages over an IPv4 Transport Network In some deployments, the network between the MAG and the LMA may only supports IPv4 transport. In this case, the Binding Revocation messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding Update and Proxy Binding Acknowledgment messages are sent using UDP encapsulation to traverse NATs, then the Binding Revocation messages are sent using the same UDP encapsulation. The same UDP port that was used for the Proxy Binding Update and Proxy Binding Acknowledgement messages will also be used when transporting Binding Revocation messages over IPv4 using UDP encapsulation. For more details on tunneling Proxy Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4]. 6. Binding Revocation Message This section defines a Binding Revocation Message that use a MH type with a Binding Revocation type field that follow the MH format described in section 6.1. [RFC3775]. The value in the Muhanna, et al. Expires March 1, 2009 [Page 10] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 Binding Revocation Type field as shown in Figure 4 defines the type of the Binding Revocation message, (BRI or BRA). If the Binding Revocation type field is set to 1, the Binding Revocation Message is a Binding Revocation Indication message as in Section 6.1. However, when the Binding Revocation type field is set to a value 2, the Binding Revocation Message is a Binding Revocation Acknowledgement message as in Section 6.2. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | B.R. Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | . Binding Revocation Message Data . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Binding Revocation Message Binding Revocation Type 8-bit unsigned integer. It defines the type of Binding Revocation Message. It can be assigned one of the following values: 0 Reserved. 1 Binding Revocation Indication Message. 2 Binding Revocation Acknowledgement Message. All other values are reserved. Binding Revocation Message Data The Binding Revocation Message Data follows the Binding Revocation Message format that is defined in this document for the specified value in the Binding Revocation Type field. It is either a BRI as in Section 6.1 or BRA as in Section 6.2. Muhanna, et al. Expires March 1, 2009 [Page 11] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 6.1. Binding Revocation Indication Message The Binding Revocation Indication (BRI) message is a Binding Revocation Message which has a MH type and a Binding Revocation Type value of 1. It is used by the revoking mobility node to inform the receiving mobility entity that the IP mobility service of a specific binding or bindings have been revoked. Binding Revocation Indication message is sent as described in Section 8.1, Section 9.1.1, and Section 10.2.1. When the value 1 is indicated in the B. R. type field of the Binding Revocation Message, the format of the Binding Revocation Message Data follows the Binding Revocation Indication message as in Figure 5 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B.R. Type = 1 | R. Trigger | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # |P|A|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Binding Revocation Indication Message Revocation Trigger 8-bit unsigned integer indicting the event which triggered the revoking node to send the BRI message. The following Revocation Trigger values are currently defined: 0 Reserved. 1 Unspecified. 2 Administrative Reason. 3 Inter-MAG Handoff - same Access Types. Muhanna, et al. Expires March 1, 2009 [Page 12] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 4 Inter-MAG Handoff - different Access Types. 5 Inter-MAG - Unknown Handoff. 6 Per-Peer Policy. 7 Revoking Node Local Policy. 8 User Initiated Session(s) Termination. 9 Access Network Session(s) Termination. 10 Possible Out-of Sync BCE State. 250-255 Reserved For Testing Purposes only. All other values are Reserved. Sequence # A 16-bit unsigned integer used by the sending mobility node to match a returned Binding Revocation Acknowledgement with this Binding Revocation Indication. Proxy Binding (P) The Proxy Binding (P) bit is set by the sending mobility node to indicate that the revoked binding is a proxy MIPv6 binding. Acknowledge (A) The Acknowledge (A) bit is set by the sending mobility node, e.g. LMA, HA, or MAG, to request a Binding Revocation Acknowledgement be returned upon receipt of the Binding Revocation Indication as in Section 8.1, Section 9.1.1, and Section 10.2.1. Global (G) The Global (G) bit is set by the sending mobility node, LMA or MAG, to request the termination of all Per-Peer mobility Bindings or Multiple Bindings which share a common identifier that are served by the sending and receiving mobility entities as in Section 9.1.1 and Section 10.2.1. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. This document does not define any new mobility option. The receiver MUST ignore and skip any options which it does not understand. These mobility Muhanna, et al. Expires March 1, 2009 [Page 13] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 option(s) are used by the receiving mobility entity to identify the specific binding or bindings that the sending mobility entity requesting to be revoked. The following options are valid in a Binding Revocation Indication: o Home Network Prefix option [RFC5213]. This option is mandatory when the (P) bit is set. o Mobile Node Identifier Option [RFC4283]. This option is mandatory when the (P) bit is set. Additionally, If the (G) bit is set by the mobile access gateway, this option carries the MAG identity. o Binding ID mobility option [ID-MCoA]. This option is mandatory if the sending mobility entity request to terminate one binding of a multi care-of addresses bindings for the same mobile node. The sending mobility entity may include more than one of the BID mobility options. o IPv4 Home Address option which contains the mobile node home IPv4 address [ID-DSMIP6]. If no options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1. 6.2. Binding Revocation Acknowledgement Message The Binding Revocation Acknowledgement (BRA) message is a Binding Revocation Message which has a MH type and a Binding Revocation Type value of 2. It is used to acknowledge the receipt of a Binding Revocation Indication message described in Section 6.1. This packet is sent as described in Section 9.2.2, Section 10.1.2, and Section 11.2. When the value 2 is indicated in the Binding Revocation type field of the Binding Revocation Message, the format of the Binding Revocation Message Data follows the Binding Revocation Acknowledgement message as in Figure 6 Muhanna, et al. Expires March 1, 2009 [Page 14] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B.R. Type = 2 | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # |P|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Binding Revocation Acknowledgement Message Status 8-bit unsigned integer indicating the result of processing the Binding Revocation Indication message by the receiving mobility entity. The following status values are currently defined. 0 success. 1 partial success. 2 Binding Does NOT Exist. 3 IPv4 HoA Binding Does NOT Exist. 4 Global Revocation NOT Authorized. 5 CAN NOT Identify Binding. 6 Revocation Failed, MN is Attached. Sequence # The sequence number in the Binding Revocation Acknowledgement is copied from the Sequence Number field in the Binding Revocation Indication. It is used by the revoking mobility entity, e.g. HA, LMA, in matching this Binding Revocation Acknowledgement with the outstanding BRI. Proxy Binding (P) The Proxy Binding (P) bit is set if the (P) bit is set in the corresponding Binding Revocation Indication message. Muhanna, et al. Expires March 1, 2009 [Page 15] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 Global (G) The Global (G) bit is set if the (G) bit is set in the corresponding BRI message. Section 9.2.2 and Section 10.1.2. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. In the case when the Status field is set to success, no mobility option is required. The mobility option(s) is usually used to communicate information of the bindings that failed the revocation procedure. The following options are valid in a Binding Revocation Acknowledgement: o Home Network Prefix option [RFC5213]. This option is mandatory when the P bit is set. o Mobile Node Identifier Option [RFC4283]. This option SHOULD be included if the Home Network Prefix option is included. o Binding ID mobility option [ID-MCoA]. This option MAY be included to indicate the specific Binding ID that the receiving node failed to revoke. If no options are present in this message, 4 octets of padding are necessary and the Header Len field of the Binding Revocation Message will be set to 1. 7. Binding Revocation Process Considerations The following subsections describe the details of the binding revocation generic process by the different mobility entities. 7.1. Sending Binding Revocation Messages When sending a Binding Revocation message, the sending mobility node, initiator, follows the rules of constructing a Mobility Header as in Section 9.2 of [RFC3775] with the exception of setting the MH Type field to . The new Mobility Header type value needs to be assigned from the same numbering space as allocated for the other Mobility Header types. 14. Security Considerations The protocol described here uses the same security association between the MN and the HA or the MAG and the LMA that has been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the session was established. If IPsec is used, The SPD of this IPsec SA MUST allow the MH type for the Binding Revocation Message defined in this document. However, in the case when the MAG sends a BRI message with the Global (G) bit is set, the LMA MUST verify that the MAG is authorized to use Per-Peer Global Revocation. 15. Acknowledgements The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- Cazavet, Domagoj Premec for their review and comments of this draft and all colleagues who have supported the advancement of this draft effort. 16. References Muhanna, et al. Expires March 1, 2009 [Page 31] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 16.1. Normative References [ID-DSMIP6] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-04 (work in progress), June 2008. [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. [ID-PMIP6-IPv4] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03 (work in progress), May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 16.2. Informative References [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003. Muhanna, et al. Expires March 1, 2009 [Page 32] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 Authors' Addresses Ahmad Muhanna Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Mohamed Khalil Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortel.com Sri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USA Email: kchowdhury@starentnetworks.com Parviz Yegani Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: pyegani@cisco.com Muhanna, et al. Expires March 1, 2009 [Page 33] Internet-Draft Binding Revocation for IPv6 Mobility August 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Muhanna, et al. Expires March 1, 2009 [Page 34]