MIP6 WG A. Muhanna Internet-Draft M. Khalil Intended status: Standards Track Nortel Expires: May 22, 2008 S. Gundavelli Cisco K. Chowdhury Starent Networks P. Yegani Cisco November 19, 2007 Binding Revocation for IPv6 Mobility draft-muhanna-mip6-binding-revocation-02.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 May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines the revocation semantics for terminating a mobile node's mobility session. These semantics are generic enough Muhanna, et al. Expires May 22, 2008 [Page 1] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 and can be applied in both client-based and network-based mobility management protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2.1. Conventions used in this document . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 3. Binding Revocation Protocol Overview . . . . . . . . . . . . . 3 4. Revocation Signaling and Use Cases . . . . . . . . . . . . . . 4 4.1. Client MIPv6 Applicability . . . . . . . . . . . . . . . . 5 4.1.1. A Mobile Node Binding Registration Termination . . . . 5 4.2. Monami6 Applicability . . . . . . . . . . . . . . . . . . 6 4.2.1. Termination of Multiple Care-of Addresses Bindings . . 6 4.2.2. Termination of All Care-of Addresses Bindings . . . . 7 4.3. Proxy MIPv6 Applicability . . . . . . . . . . . . . . . . 7 4.3.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8 4.3.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 9 4.3.3. Mobile Access Gateway Revoke A PMIPv6 Binding . . . . 9 4.3.4. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings . . 11 5. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 12 7. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 12 8. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 14 9. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 14 10. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Binding Revocation Indication Message . . . . . . . . . . 16 10.2. Binding Revocation Acknowledgement Message . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Muhanna, et al. Expires May 22, 2008 [Page 2] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 1. Introduction In the case of Mobile IPv6 and for administrative reasons, 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 [RFC-3344] has been deployed a similar Mobile IPv4 registration revocation mechanism has been specified as in [RFC- 3543]. 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 a Proxy Mobile IPv6 signaling. The proposed revocation mechanism uses generic message properties which is applicable to Mobile IPv6 [RFC-3775] and Proxy Mobile IPv6 [PMIP6-SPEC] and can be used by any two IP mobility entities. As an example, this mechanism allows a local mobility agent, involved in providing IP mobility services to a mobile node, to notify the mobility access gateway of the termination of a mobile node binding registration. In another example, a mobility access gateway can use this mechanism to notify its local mobility anchor peer with a bulk termination of all Proxy MIPv6 bindings that are registered with the local mobility anchor and currently served by the mobility 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 RFC 2119 [RFC-2119]. 2.2. Terminology All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 specification [RFC-3775] and Proxy Mobile IPv6 specification [PMIP6-SPEC]. 3. Binding Revocation Protocol Overview This specification defines a binding revocation protocol for Mobile IPv6 and its extensions, e.g. PMIPv6, whereby a mobility node can communicate to the mobile node or another mobility node of the termination of the mobile node registration binding. Muhanna, et al. Expires May 22, 2008 [Page 3] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 In the case of Mobile IPv6 [RFC-3775], 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 mobile node identity. When the mobile node receives a BRI message with its HoA included and process the BRI message, the mobile node sends a Binding Revocation Acknowledgement (BRA) message if the home agent had the A bit set in the BRI message. Similarly, in the case of Proxy Mobile IPv6 [PMIP6-SPEC], 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 [PMIP6-SPEC]and the MN-ID option [RFC-4283] to indicate to the mobility access gateway the identity of the PMIPv6 binding that needs to be terminated. If the mobility access gateway successfully process the BRI message and the local mobility anchor had the A bit set in the BRI message, the mobility access gateway sends a BRA message in response to the local mobility anchor BRI message. On the other hand, the mobility access gateway usually sends a de- registration message by sending a Proxy BU with a lifetime of zero to indicate to the local mobility anchor of the termination of the PMIPv6 mobile node binding registration. In this case, the mobility access gateway include the MN home network prefix option and the MN-ID option as per [PMIP6-SPEC] in order for the local mobility anchor to identify the mobile node PMIPv6 binding. However, in the case when the mobility access gateway communicates a bulk termination of PMIPv6 sessions, the mobility access gateway sends a BRI message with the G bit set and includes the mobility access gateway IP address in the care-of address option and optionaly its identity in the MN-ID option. When the local mobility anchor 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, the local mobility anchor sends a BRA message in response to the mobile access gateway BRI message if the A bit in the BRI message is set. 4. Revocation Signaling and Use Cases This section defines how the revocation signaling can be used by mobility entities for the purpose of revoking a binding registration, discontinue of the IP mobility services, and state cleanup. The Muhanna, et al. Expires May 22, 2008 [Page 4] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 subsections below define the different applicable use cases. 4.1. Client MIPv6 Applicability Binding revocation mechanism is applicable to Client Mobile IPv6 session when the home agent needs to inform the mobile node that its binding registration has been revoked for an administrative reason. This mechanism will enable the home domain to dynamically allow the Mobile IPv6 user to act upon the message in order to not have an unexpected interrupted mobile IPv6 services. One of the important scenarios that is applicable to Mobile IPv6 protocol [RFC-3775] is when a mobile node returns home. According to RFC3775, the mobile node is recommended to send a BU message with lifetime of zero, however, RFC3775 did not mandate this behavior on the mobile node. In this case, if the home agent detects that the mobile node has returned home but did not send a de-registration BU, the home agent may send a BRI message to the mobile node using the same security association that the mobile node and home agent negotiated and used during the exchange of the initial BU and BA messages. 4.1.1. A Mobile Node Binding Registration Termination In this case, 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 BRI includes the mobile node home address, HoA option. If the mobile node processes the BRI message, it SHOULD send a BRA message to the home agent if the A bit in the BRI message is set. Figure-3 illustrates the message sequencing when home agent revokes a mobile node binding registration. MN HA | | | BRI[seq.#, A bit, HoA & NAI options]| |<------------------------------------| | | | | | BRA[seq.#x, HoA & NAI options] | |------------------------------------>| | | | | Muhanna, et al. Expires May 22, 2008 [Page 5] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 Figure 1: Home Agent Revokes a Mobile Node Binding Registration 4.2. Monami6 Applicability 4.2.1. Termination of Multiple Care-of Addresses Bindings In the case of Monami6 protocol, a mobile node is able to register multiple care-of addresses for the same home address [Monami6-SPEC]. In this case 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 new Binding ID mobility option [Monami6-SPEC]. In this case, the home agent 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 SHOULD send a BRI message to the mobile node with HoA and BID options included. If the home agent needs to revoke more than one of the mobile node registered care-of addresses, the home agent SHOULD send the mobile node a BRI message with the HoA option and all the BID options which reference these care-of Addresses. Figure-7 illustrates the message flow when the home agent revokes two registered Care-of addresses for the same MN in a single BRI message. The home agent can revoke any registered bindings by sending send a BRI message to the respected mobile node. HA Binding Cache ================ MN-BID1 [CoA1+HoA] MN HA MN-BID2 [CoA2+HoA] | | MN-BID3 [CoA3+HoA] |BRI[seq.#, A bit, HoA, BID1, BID4 options] | MN-BID4 [CoA4+HoA] |<------------------------------------------| | | | | | | | BRA[seq.#, HoA, BID1, BID4 options] | |------------------------------------------>| | | | | Muhanna, et al. Expires May 22, 2008 [Page 6] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 Figure 2: Home Agent Revokes MN's Specific Registered Care-of Addresses Bindings 4.2.2. Termination of All Care-of Addresses Bindings In the case when the home agent revokes all of the mobile node registered bindings, the home agent SHOULD send a BRI message with the HoA option only. Figure-8 illustrates the message flow when the home agent revokes all registered Care-of addresses bindings for a MN in a single BRI message. HA Binding Cache ================ MN-BID1 [CoA1+HoA] MN HA MN-BID2 [CoA2+HoA] | | MN-BID3 [CoA3+HoA] | BRI[seq.#, A bit, HoA option] | |<------------------------------------------| | | | | | | | BRA[seq.#, HoA options] | |------------------------------------------>| | | | | Figure 3: Home Agent Revokes All MN's Registered Care-of Addresses Bindings 4.3. Proxy MIPv6 Applicability 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 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, Muhanna, et al. Expires May 22, 2008 [Page 7] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 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-IPV4-PMIP6]. When the mobile access gateway receives and successfully processes a BRI message with the A bit is set, the mobile access gateway MUST send a BRA message to the local mobility anchor. Similarly if the local mobility anchor receives and successfully process a BRI message with the A bit is set, the local mobility anchor MUST send a BRA message to the mobile access gateway. 4.3.1. Local Mobility Anchor Revokes A PMIPv6 Binding In this case, the local mobility anchor MAY send a BRI message to the mobile access gateway, hosting a specific proxy mobile IPv6 session, to indicate that the mobile node binding has been terminated and the mobile access gateway can clean up the associated resources. If the mobile access gateway successfully processes the BRI message, it MUST send a BRA message in response to the LMA if the A bit in the BRI message is set. In this case, the MAG SHOULD send a Router Advertisement message to the MN with the home network prefix lifetime is set to zero. As an example, Figure-4, 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 location. 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 MAY send a BRI message to the source MAG to clean up the resources reserved for the specified MN. If the LMA sets the A bit in the BRI and the MAG processes the BRI message, the MAG MUST send a BRA message to indicate the success or failure of the termination of the mobile node binding. The process identified above can be used by the LMA in scenarios other than the inter-MAG handoff to indicate to the peer MAG that a specific proxy mobile IPv6 binding or bindings have been revoked. Muhanna, et al. Expires May 22, 2008 [Page 8] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 sMAG tMAG LMA | | | | | PBU | | |--------------------------->| | | PBU triggers | | BRI Msg to sMAG | | | | | PBA | | |<---------------------------| | | | | | | | BRI [seq.#, P,A bits, HoA, NAI options] | |<-----------------------------------------| | | | | | | | | | | | | | BRA [seq.#, P bit, HoA, NAI options] | |----------------------------------------->| | | | | | | Figure 4: LMA Revokes a MN Registration During Inter-MAG Handoff 4.3.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings The local mobility anchor MAY send a BRI message to indicate that all bindings which are hosted by the peer mobile access gateway and registered with the local mobility anchor MUST be revoked by setting the G bit. In this case, the local mobility anchor includes the LMA IP address in the home address option. Optionally, the LMA may also include its identity in the MN-ID option. 4.3.3. Mobile Access Gateway Revoke A PMIPv6 Binding In the case when the mobile access gateway receives a direct or indirect indication or it finds that the mobile node has moved a way and no longer attached to the it, the mobile access gateway and based on local policy MAY need to indicate to the local mobility anchor that the mobile node session binding has been cleaned up at the MAG and the LMA needs to clean up the allocated and reserved resources. In this case the MAG SHOULD send a de-registration by sending a PBU message with a lifetime of zero. When the LMA process the de- registration message, the LMA MUST send a PBA message in response to Muhanna, et al. Expires May 22, 2008 [Page 9] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 the MAG [RFC-3775]. Since there is no guaranteed indication to the LMA that the MAG has sent the de-registration message due to a mobile node move during an inter-MAG handoff, the LMA SHOULD start a MinBCEDelWait as per [PMIP6-SPEC] to make sure that the mobile node session binding survives an inter-MAG handoff. Figure-5 and Figure-6 illustrate the message flow for two scenarios. sMAG tMAG LMA | | | | | | | | | | PBU [seq.#,lifetime=0, HoA, MN-ID options] | |---------------------------------------------->| | | Start | | MinBCEDelWait | | timer | | | | PBA [seq.#, P bit, HoA, MN-ID option] | |<----------------------------------------------| | | | | | | | | PBU | | |--------------------------->| | | Cancel | | MinBCEDelWait | | timer | | | | | PBA | | |<---------------------------| | | | | | | Figure 5: sMAG Revokes a MN Registration During Inter-MAG Handoff Muhanna, et al. Expires May 22, 2008 [Page 10] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 MAG LMA | | Indication to MAG | MN Exited Network | | | | PBU [seq.#,lifetime=0, HoA, MN-ID options] | |--------------------------------------------->| | Start | MinBCEDelWait | timer | | | BRA [seq.#, P bit, HoA, MN-ID options] | |<---------------------------------------------| | | | MinBCEDelWait | timer Expires | | | LMA Cleans Up | MN Binding | | | | Figure 6: MAG Informs LMA of Revoking the MN Binding and Resources 4.3.4. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings The mobile access gateway MAY send a BRI message to request that all mobility sessions which are registered at the LMA and attached to the MAG MUST be revoked by setting the G bit. In this case, the mobile access gateway includes its IP address in the care-of-address option. Optionally, the MAG may also include its identity in the MN-ID option. This case is very useful to gracefully terminates all mobility sessions between the MAG and the LMA whenever needed. 5. Security Model The protocol described here uses the same IPsec security association between the MN and the HA as per [RFC-3775] that has been used during the exchange of the Client MIPv6 signaling messages. In the case of PMIPv6, the protocol uses the same security association between the Muhanna, et al. Expires May 22, 2008 [Page 11] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 MAG and LMA that has been used to exchange the Proxy MIPv6 signaling messages when the session was established. In the case when the LMA receive a BRI which indicates a bulk termination, the LMA MUST verify that the MAG sending the revocation indication message is authorized for this kind of revocation. 6. Home Agent Operation o When the home agent sends a BRI message to terminate a mobile node only mobile IPv6 binding or all of the mobile node's registered care-of addresses bindings, the home agent include only the mobile node home address, HoA, option. o When sending a BRI message, in addition to the mobile node HoA option, The home agent MAY include one BID option in addition to the mobile node HoA option in the BRI message to terminate a specific binding for the mobile node that registered multiple care-of addresses bindings. Optionally, the home agent may include more than one BID options in addition to the mobile node HoA option. o The home agent set the A bit to request the mobile node to send a BRA message if the mobile node successfully processes the BRI message. o The home agent MUST use the IPsec security association that has been used during the MIPv6 binding registration with the HA to secure the BRI and BRA messages transmission with the mobile node. 7. Local Mobility Anchor Operation o Local mobility anchor MUST include the mobile node HNP and the MN-ID options when it sends a BRI message to the MAG to terminate a mobile node session. The local mobility anchor MUST set the P bit in the BRI message to indicate that the binding is a proxy MIPv6 binding. The LMA MAY set the A bit to indicate that the MAG should send a BRA message to acknowledge processing the BRI message. o Local Mobility Anchor MUST set the G bit in the BRI message to indicate to the mobile access gateway a bulk termination of all mobility sessions between the LMA and MAG. In this case, LMA MUST Muhanna, et al. Expires May 22, 2008 [Page 12] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 set its IP address in the HNP. Optionally, the LMA MAY include its own identity in the MN-ID option. o In the case when the LMA can identify several mobile nodes bindings per a single subnet prefix, LMA may send a BRI message with the specific prefix in the home network prefix option after setting the P and A bits to revoke the binding registration of all these mobile nodes. o When the local mobility anchor receives a de-registration PBU message from a MAG on the secure tunnel, LMA define the mobile node or nodes that are revoked by this de-registration by examining the HNP option. If the HNP is included and the home network prefix match one of the bindings in the LMA cache entry, LMA revokes that specific binding and sends PBA in response as per [PMIP6-SPEC]. o In the case of mobile node handover from the source MAG to the target MAG, LMA MAY receive a PBU from the target MAG to update the MN BCE with the new CoA. After LMA update the MN BCE, LMA SHOULD send a BRI with the P and A bits set and include the mobile node home network prefix in the HNP option and the MN-ID option to indicate to the source MAG to clean up the resources associated with the mobile node. o When LMA receives a de-registration PBU message from the MAG and the LMA fails to find the associated BCE, LMA MAY send a PBA message with status is set to revocation failed "MN binding does not exist". The LMA MAY choose NOT to respond to the de- registration PBU message, however, the MAG MAY retransmit the de- registration PBU message. o Whenever LMA receives BRI message with the A bit is set and successfully process the BRI message, the LMA MUST send a BRA message in response to the BRI message to the mobile access gateway. LMA must copy the sequence number from the BRI field into the sequence number field of the BRA message. If the BRI message has the G bit set, the local mobility anchor must verify that the sending MAG is authorized and can participate in bulk termination before terminating the respected mobility sessions. o The local mobility anchor MUST use the same security association that has been used during the Proxy MIPv6 sessions with the specified MAG to secure the BRI and BRA messages transmission with the MAG. Muhanna, et al. Expires May 22, 2008 [Page 13] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 8. Mobile Access Gateway Operation o When MAG revokes a specific session of a mobile node, MAG SHOULD send a de-registration PBU message with the per-MN home network prefix and the MN-ID options included. o Mobile Access Gateway MUST set the G bit in the BRI message to indicate to the local mobility anchor a bulk termination of all mobility sessions between the LMA and MAG. In this case, MAG MUST set its IP address in the care-of address option. Optionally, the MAG MAY include its own identity in the MN-ID option. o When the mobile access gateway receives a BRI message from the LMA on the secure tunnel with the LMA, MAG locates the mobile node or nodes that are being revoked as per the received BRI by examining the mobility options included in the received BRI message. If the home address option is included, MAG MUST revoke that MN specific session and sends a BRA message to the LMA after copying the sequence number from the BRI into the BRA sequence number field. If the Home Network Prefix option is included, the MAG revokes all mobile nodes BCE which use the specified prefix. However, if the G bit is set and the LMA IP address is included in the HNP option, the MAG must revoke all mobility sessions which registered between the MAG and the peer LMA. o When the MAG receives a BRI message from the LMA and the MAG fails to find the associated BCE, the MAG SHOULD send BRA message with the status field is set "MN binding does not exist" to indicate revocation has failed . The MAG MAY choose not to respond to the BRA message, however, the LMA will retransmit the BRI message. o Whenever the MAG receives a BRI message with the A bit is set and successfully process the BRI message, the MAG MUST send a BRA message in response to the BRI message to the local mobility anchor. MAG must copy the sequence number from the BRI field into the sequence number field of the BRA message. o The MAG MUST use the security association that has been used during the Proxy MIPv6 sessions establishment with the peer LMA to secure the BRI and BRA messages transmission with the LMA. 9. Mobile Node Operation o When the mobile node receives a BRI message from the HA on the secure tunnel with the HA, the mobile node MUST verify that the IP Muhanna, et al. Expires May 22, 2008 [Page 14] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 address included in the home address option is its HoA. The mobile node MUST verify that the BRI P bit is not set. If the MN process the BRI, the MN SHOULD send a BRA message to the HA using the same sequence number in the received BRI message as the sequence number of the BRA. o If the MN has registered multiple care-of addresses with its HA, the MN may receive a BRI from its home agent to revoke the binding registration of a single care-of address binding or multiple care-of addresses bindings. When such a MN receives a BRI from its home agent, the MN MUST verify which binding has been revoked by examining the content of the BRI message. If the MN received a BRI with a single BID option and the HoA option, the mobile node MUST consider this care-of address binding has been revoked and the MN no longer can use this care-of address binding. Furthermore, If the MN receives a BRI message from its home agent with the HoA and multiple BID options, the mobile node MUST consider these care-of addresses bindings revoked and it can no longer use these bindings. However, if the MN receives a BRI message from its home agent with the HoA option only, the MN must consider all its registered care-of addresses associated with this home address have been revoked and it can no longer use anyone of them. o When the MN receives a BRI message from the HA which does not belong to the MN binding with this HA, the MN SHOULD send BRA message with the status field is set "MN binding does not exist" to indicate revocation has failed . The MN MAY continue to use its assigned HoA to access it IP mobility service. o The MN MUST use the security association that has been used during the MIPv6 binding registration with the HA to secure the BRI and BRA messages transmission with the HA. o It is recommended that if the MN receives and process a BRI message that the MN SHOULD send a BRA message if the HA had the A bit set in the BRI. 10. Message Formats This section defines two new mobility header messages. Muhanna, et al. Expires May 22, 2008 [Page 15] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 10.1. Binding Revocation Indication Message The Binding Revocation Indication (BRI) message is used by the LMA to notify the MAG that the mobility service of a specified MN binding or bindings have been revoked in order for the MAG to take the proper action and cleanup the associated resources. This message can also be used by the HA to indicate to the MN that its mobility binding has been revoked. The BRI message uses the MH Type value (TBD, to be assigned by IANA). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as presented in Figure-1: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P|A|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Binding Revocation Indication Message Muhanna, et al. Expires May 22, 2008 [Page 16] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 Sequence # A two byte sequence number. The mobility agent, LMA/HA or MAG sets this sequence number to the next available number after the last used sequence number. The sending mobility node use this sequence number to match the BRA to the outstanding BRI message. 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 entry. Acknowledge (A) The Acknowledge (A) bit is set by the sending mobility node, LMA/ HA to request the peer mobility node to acknowledge receiving the BRI message via a BRA message. Global Per-Peer Bindings (G) The Global Per-Peer Bindings (G) bit is set by the sending mobility node, LMA or MAG, to request the receiving peer mobility node to terminate all mobility sessions created between the two mobility entities. Reserved This field is reserved for future use. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Mobility Options A mobility option(s) that is used to identify a specific binding or bindings that their registration(s) are being revoked; e.g. HNP [PMIP6-SPEC], MN-ID [RFC-4283], Binding ID [Monami6-SPEC], and HoA [RFC-3775] options. 10.2. Binding Revocation Acknowledgement Message The receiver of the BRI message will send the Binding Revocation Acknowledge (BRA) in response to a Binding Revocation Indication message. The BRA message uses the MH Type value (TBD, to be assigned by IANA). When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as presented in Figure-2: Muhanna, et al. Expires May 22, 2008 [Page 17] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |P|G| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Binding Revocation Acknowledgement Message Sequence # A two byte sequence number. When the MN or MAG sends a BRA message, it must copy the sequence number from the sequence number field of the corresponding BRI message. Status A one byte which indicates the result of processing the corresponding BRI message by the receiving mobility entity. 0 success. 1 failure unspecified. 2 MN binding does not exist. Proxy Binding (P) The Proxy Binding (P) bit is set if the same P bit is set in the corresponding BRI message. Global Per-Peer Bindings (G) The Global Per-Peer Bindings (G) bit is set if the same G bit is set in the corresponding BRI message. Reserved This field is reserved for future use. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Mobility Options The mobility option(s) usually match those received in the Muhanna, et al. Expires May 22, 2008 [Page 18] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 corresponding BRI message. 11. IANA Considerations This document defines two new Mobility Header type messages, BRI and BRA, as described in Section 3.1. The new Mobility Header type values needs to be assigned from the same numbering space as allocated for the other Mobility Header types. 12. Security Considerations The protocol described here uses the same per node 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. However, in the case when the MAG sends a BRI message with the G bit is set, the LMA MUST verify that the MAG is authorized to indicate such event. 13. Acknowledgements The authors would like to thank Ryuji Wakikawa and Bruno Mongazon- Cazavet for their detailed review and comments of this draft and all colleagues who have supported the advancement of this draft effort. 14. References 14.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2003. [PMIP6-SPEC] Gundavelli, S., et al., "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-07 (work in progress), May 2008. Muhanna, et al. Expires May 22, 2008 [Page 19] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 4303, December 2005. [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [Monami6-SPEC] Wakikawa, R., Ernst, T., Nagami, K., and Devarapalli, V. "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-03 (work in progress), January 2008. [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, November 2005. 14.2. Informative References [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC-3543] S. Glass and M. Chandra, "Registration Revocation in Mobile IPv4", RFC3543, August 2003. [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-01.txt, May 2007. [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Authors' Addresses Ahmad Muhanna Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Muhanna, et al. Expires May 22, 2008 [Page 20] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 Mohamed Khalil Nortel Networks 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 May 22, 2008 [Page 21] Internet-Draft Binding Revocation for IPv6 Mobility November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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 May 22, 2008 [Page 22]