[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-muhanna-mext-binding-revocation) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 5846

Network Working Group                                         A. Muhanna
Internet-Draft                                                 M. Khalil
Intended status: Standards Track                                  Nortel
Expires: August 2, 2009                                    S. Gundavelli
                                                           Cisco Systems
                                                            K. Chowdhury
                                                        Starent Networks
                                                               P. Yegani
                                                        Juniper Networks
                                                        January 29, 2009


                  Binding Revocation for IPv6 Mobility
               draft-ietf-mext-binding-revocation-03.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 August 2, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Muhanna, et al.          Expires August 2, 2009                 [Page 1]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   to this document.

Abstract

   This document defines the revocation semantics for terminating a
   mobile node's mobility session and associated resources.  These
   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 . . 10
       3.4.3.  Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10
   4.  Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Exchanging Binding Revocation Messages over an IPv4
       Transport Network  . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Binding Revocation Message . . . . . . . . . . . . . . . . . . 11
     6.1.  Binding Revocation Indication Message  . . . . . . . . . . 12
     6.2.  Binding Revocation Acknowledgement Message . . . . . . . . 15
   7.  Binding Revocation Process Considerations  . . . . . . . . . . 17
     7.1.  Sending Binding Revocation Messages  . . . . . . . . . . . 17
     7.2.  Receiving Binding Revocation Messages  . . . . . . . . . . 18
     7.3.  Retransmission of Binding Revocation Indication  . . . . . 18
   8.  Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19
     8.1.  Sending Binding Revocation Indication  . . . . . . . . . . 19
     8.2.  Receiving Binding Revocation Acknowledgement . . . . . . . 20
   9.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . . 21
     9.1.  Binding Revocation Initiator . . . . . . . . . . . . . . . 21
       9.1.1.  Sending Binding Revocation Indication  . . . . . . . . 21
       9.1.2.  Receiving Binding Revocation Acknowledgement . . . . . 24
     9.2.  Binding Revocation Responder . . . . . . . . . . . . . . . 24
       9.2.1.  Receiving Binding Revocation Indication  . . . . . . . 24



Muhanna, et al.          Expires August 2, 2009                 [Page 2]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


       9.2.2.  Sending Binding Revocation Acknowledgement . . . . . . 25
   10. Mobile Access Gateway Operation  . . . . . . . . . . . . . . . 26
     10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26
       10.1.1. Receiving Binding Revocation Indication  . . . . . . . 26
       10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 28
     10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 29
       10.2.1. Sending Binding Revocation Indication  . . . . . . . . 29
       10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 30
   11. Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 30
     11.1. Receiving Binding Revocation Indication  . . . . . . . . . 30
     11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 32
   12. Protocol Configuration Variables . . . . . . . . . . . . . . . 32
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 33
     16.2. Informative References . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
































Muhanna, et al.          Expires August 2, 2009                 [Page 3]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


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 <IANA-TBD> 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 August 2, 2009                 [Page 4]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


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 in the type 2 routing header 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 August 2, 2009                 [Page 5]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   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 recover its 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 Type 2 routing 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 in the 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 Type 2 Hdr + BRI [seq.#, A bit]   |
         |<------------------------------------------|
         |                                           |
         |                                           |
         |                                           |
         |  HoA in Destination Option BRA[seq.#]     |
         |------------------------------------------>|
         |                                           |
         |                                           |



      Figure 1: Home Agent Revokes a Mobile Node Binding Registration








Muhanna, et al.          Expires August 2, 2009                 [Page 6]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


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 is in the Type 2 routing 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 Binding ID 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.#, Status]           |
      |------------------------------------------>|
      |                                           |
      |                                           |






Muhanna, et al.          Expires August 2, 2009                 [Page 7]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings


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 is included in the Type 2 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 described 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 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



Muhanna, et al.          Expires August 2, 2009                 [Page 8]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   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
   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.#, Status, P bit]        |
               |----------------------------------------->|
               |             |                            |
               |             |                            |



     Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff








Muhanna, et al.          Expires August 2, 2009                 [Page 9]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


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.


3.4.3.  Mobile Access Gateway Revokes 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 traffic selectors associated with the SP protecting BU and
   BA MUST be extended to include Binding Revocation Signaling MH type
   <IANA-TBD>.  Extending the traffic selectors of the SP in order to
   reuse the SA protecting BU and BA (instead of creating new ones)
   ensures that those SA will be up and running when the revoking entity
   needs to send a Binding Revocation Signaling message.

   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
   support 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



Muhanna, et al.          Expires August 2, 2009                [Page 10]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   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 the Binding Revocation Message format using a MH
   Type <IANA-TBD> as illustrated in Figure 4.  The value in the Binding
   Revocation Type field defines whether the Binding Revocation message
   is a 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, if the value is 2, it 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








Muhanna, et al.          Expires August 2, 2009                [Page 11]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   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.



6.1.  Binding Revocation Indication Message

   The Binding Revocation Indication (BRI) message is a Binding
   Revocation Message which has a MH type <IANA-TBD> 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|V|G|     Reserved          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




              Figure 5: Binding Revocation Indication Message


   Revocation Trigger

      8-bit unsigned integer indicating the event which triggered the
      revoking node to send the BRI message.  The following Revocation
      Trigger values are currently defined:



Muhanna, et al.          Expires August 2, 2009                [Page 12]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


          0  Reserved
          1  Unspecified
          2  Administrative Reason
          3  Inter-MAG Handoff - same Access Types
          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  IPv4 HoA Lease Expires
          11  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(s) 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.

   IPv4 HoA Binding Only (V)

      The IPv4 HoA Binding Only (V) bit is set by the sending mobility
      node, HA or LMA, to request the receiving mobility entity the
      termination of the IPv4 Home Address binding only as in
      Section 8.1, and Section 9.1.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.




Muhanna, et al.          Expires August 2, 2009                [Page 13]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   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
      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 MAY be used
      when the (P) bit is set.  This option MUST be present when the BRI
      is used to revoke a single PMIP binding cache entry.

   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 Binding
      ID mobility options.

   o  IPv4 Home Address option which contains the mobile node home IPv4
      address [ID-DSMIP6].  This option is included only when the IPv4
      HoA Binding only (V) bit is set.

   o  Alternate Care-of Address mobility option [RFC3775].  This option
      MAY be included to indicate the Care-of Address of the mobile
      node's binding that is being revoked.  In the case when the Global
      (G) bit set, this option identifies all the mobility bindings that
      share the same care-of address.  Additionally, if the Global (G)
      bit set, more than one Alternate Care-of Address mobility options
      MAY be present in the BRI message.

   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.




Muhanna, et al.          Expires August 2, 2009                [Page 14]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


6.2.  Binding Revocation Acknowledgement Message

   The Binding Revocation Acknowledgement (BRA) message is a Binding
   Revocation Message which has a MH type <IANA-TBD> 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



       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|V|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
          128  Binding Does NOT Exist







Muhanna, et al.          Expires August 2, 2009                [Page 15]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


          129  IPv4 HoA Binding Does NOT Exist
          130  IPv4 HoA Option Required
          131  Global Revocation NOT Authorized
          132  CAN NOT Identify Binding
          133  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.

   IPv4 HoA Binding Only (V)

      The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in
      the corresponding BRI message.

   Global (G)

      The Global (G) bit is set if the (G) bit is set in the
      corresponding BRI message.

   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:






Muhanna, et al.          Expires August 2, 2009                [Page 16]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   o  Home Network Prefix option [RFC5213].  This option MAY be included
      when the (P) bit is set.

   o  Mobile Node Identifier Option [RFC4283].  This option MAY be
      included when the (P) bit is set.  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 <IANA-TBD and the appropriate value of the Binding
   Revocation Type field.


   The mobility entity which initiates the revocation process,
   initiator, MUST use the underlying IPsec security association that
   has been used during the mobile node binding registration to secure
   the BRI and BRA messages transmission with the responding mobility
   entity, responder.


   When a mobility entity initiate the binding revocation process by
   sending a Binding Revocation Indication message, the initiator MUST
   construct the BRI message as described in Section 6.1.  In the BRI
   message, the initiator MUST set the Sequence Number field to the next
   sequence number available for Binding Revocation.  Since sending BRI
   messages is not done on a regular basis, a 16 bit sequence number
   field is large enough to allow the initiator to match the BRA to the
   outstanding BRI with (A) bit set using the sequence number field
   only.





Muhanna, et al.          Expires August 2, 2009                [Page 17]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   On the other hand, when the responder acknowledge the BRI message by
   sending a BRA, the responder MUST construct the Binding Revocation
   Acknowledgement as described in Section 6.2.  In this case, the
   responder MUST set the Sequence Number field by copying the value
   from the Sequence Number field of the received Binding Revocation
   Indication.  Additionally, it MUST set the status field to a valid
   value that reflects the processing of the received Binding Revocation
   Indication.

7.2.  Receiving Binding Revocation Messages

   When receiving a Binding Revocation message, the receiving mobility
   node MUST verify the Mobility Header as in [RFC3775].  If the packet
   is dropped due to failing any of the Mobility Headers test check, the
   receiving node MUST follow the processing rules as in Section 9.2 of
   [RFC3775].  For example, it MUST send a Binding Error message with
   the Status field set to 2 (unrecognized MH Type value) if it does not
   support the received binding revocation message type.


   Since some mobility entities, e.g.  LMA and MAG, are allowed to
   receive and possibly send a BRI or a BRA for different cases, IPsec
   mechanism will prevent any possible man in the middle reflection
   attack.


   Upon receiving a packet carrying a Binding Revocation Indication, the
   receiving mobility entity, responder, validates that the packet was
   received protected with the underlying IPsec protection with the
   responding mobility entity.


   Upon receiving a packet carrying a Binding Revocation
   Acknowledgement, the receiving mobility entity, initiator, MUST
   validate that Sequence Number field matches the Sequence Number of an
   outstanding Binding Revocation Indication that was sent by the
   initiator.  If the Sequence Number does not match any sequence number
   of any of the outstanding BRI, the receiving node MUST ignore the
   message but MAY log the event.

7.3.  Retransmission of Binding Revocation Indication

   If the sending mobility entity does not receive a Binding Revocation
   Acknowledgement in response to the outstanding Binding Revocation
   Indication before the MINDelayBRIs timer expires, the mobility
   entity, e.g.  LMA, may retransmit the same BRI message up to the
   BRIMaxRetriesNumber as defined in Section 12.  If the revoking
   mobility entity does not receive a BRA message after the maximum



Muhanna, et al.          Expires August 2, 2009                [Page 18]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   number of retransmits have been sent, the revoking mobility entity
   can clean the mobile node binding cache and all resources associated
   with this binding.  The revoking mobility entity may log the event.


8.  Home Agent Operation

8.1.  Sending Binding Revocation Indication

   When an event requires the home agent to terminate a mobile node
   mobile IPv6 registration, e.g. for administrative reason, the home
   agent sends a Binding Revocation Indication message to the mobile
   node to inform the mobile node that its specified binding has been
   revoked and it will no longer be able to receive an IP connectivity
   via its binding with the home agent.

   To terminate a mobile node registration and its current binding with
   the home agent, the home agent sends a packet to the mobile node
   containing a Binding Revocation Indication, with the packet
   constructed as follows:

   o  The Acknowledge (A) bit MAY be set in the BRI to request the
      mobile node to send a Binding Revocation Acknowledgement upon
      receipt of the BRI.

   o  The Revocation Trigger field MUST be set in the Binding Revocation
      Indication to indicate to the mobile node the reason for revoking
      its IP mobility binding with the home agent.  The Revocation
      Trigger may be used by the mobile node to take further steps if
      necessary.

   o  The Binding Revocation Indication MUST be sent using a type 2
      routing header which contains the mobile node's registered IPv6
      home address for the binding being revoked.

   o  The care-of address for the binding MUST be used as the
      destination address in the packet's IPv6 header, unless an
      Alternate Care-of Address mobility option is included in the
      Binding Revocation Indication.

   o  If the home agent needs to only revoke the mobile node's IPv4 home
      address binding, the home agent MUST set the IPv4 HoA Binding Only
      (V) bit and MUST include the mobile node's registered IPv4 home
      address that is being revoked in the IPv4 Home Address option.


   The Acknowledge (A) bit in the Binding Revocation Indication requests
   the mobile node to return a Binding Revocation Acknowledgement in



Muhanna, et al.          Expires August 2, 2009                [Page 19]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   response to this Binding Revocation Indication.  As described in
   Section 7.3, the home agent SHOULD retransmit this Binding Revocation
   Indication to the mobile node before terminating its IP connection
   until it receives a matching Binding Revocation Acknowledgement or
   the BRIMaxRetransmitNumber has been reached.

   When the home agent sends a BRI to the mobile node with the (A) bit
   set, the home agent sets a flag in the mobile node BCE to indicate
   that revocation is in progress and starts the MINDelayBRIs timer.
   The home agent maintains the mobile node BCE in this state until it
   receives a Binding Revocation Acknowledgement or the
   BRIMaxRetransmitNumber is reached.

   In a race condition case, the home agent may receive a BU from the
   mobile node while the mobile node's BCE has the revocation in
   progress flag set, the home agent should handle this case based on
   the reason for sending the Binding Revocation Indication message and
   its local policy.  In this case, if the home agent accepts the BU, it
   needs to update the mobile node BCE accordingly, e.g. removing the
   revocation in progress flag.

   When the home agent needs to revoke one or more of a mobile node
   bindings that were created using Multi Care-of address registration
   as in [ID-MCoA], the home agent MUST include all the related Binding
   ID options that identify these bindings in the Binding Revocation
   Indication message.  In the case when the home agent needs to revoke
   all of the mobile node bindings, the home agent MUST NOT include any
   of the Binding ID options.

   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.

8.2.  Receiving Binding Revocation Acknowledgement

   When the home agent receives a packet carrying a valid BRA that was
   successfully processed as in Section 7.2, the home agent SHOULD
   examine the Status field as follows:

   o  If the Status field indicates that the Binding Revocation
      Indication was processed successfully, the home agent deletes the
      MINDelayBRIs timer and the mobile node bindings and all related
      resources.

   o  If the Status field indicates any value other than success, the
      home agent SHOULD examine any mobility options included in the
      Binding Revocation Acknowledgement.  The home agent MAY log the
      appropriate event to reflect the status of the received BRA.



Muhanna, et al.          Expires August 2, 2009                [Page 20]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


9.  Local Mobility Anchor Operation

9.1.  Binding Revocation Initiator

9.1.1.  Sending Binding Revocation Indication

   When an event requires the local mobility agent to terminate a mobile
   node proxy mobile IPv6 registration, e.g. for administrative reason
   or inter-MAG handover, the local mobility agent sends a Binding
   Revocation Indication message to the mobile access gateway which host
   the mobile node proxy CoA to indicate that the mobile node's
   specified binding should be removed.  It also indicate that the LMA
   will no longer maintain a tunnel for this mobile node binding which
   points to the mobile node proxy CoA that is hosted at this MAG.

   To terminate a mobile node proxy mobile IPv6 registration and its
   current PMIPv6 binding with the local mobility agent, the LMA sends a
   packet to the MAG containing a BRI message following the procedure in
   Section 7.1 and the following rules:

   o  The Acknowledge (A) bit MAY be set in the Binding Revocation
      Indication to request the mobile access gateway to send a Binding
      Revocation Acknowledgement upon receipt of the BRI.

   o  The Proxy Mobile IP (P) bit MUST be set in the BRI message to
      indicate that the binding being revoked is a proxy Mobile IPv6
      binding.

   o  The Revocation Trigger field MUST be set in the Binding Revocation
      Indication to indicate to the mobile access gateway the reason for
      removing the specified mobile node proxy mobile IPv6 binding at
      the LMA.  The Revocation Trigger may be used by the mobile access
      gateway to learn the mobile node's latest movement.

   o  In case of revoking all Per-Peer bindings, the Global (G) bit MUST
      be set and the Revocation Trigger MUST contain a value of "Per-
      Peer Policy" in the Binding Revocation Indication to request the
      mobile access gateway to remove all Per-Peer bindings that are
      registered with the LMA and hosted at this MAG.

   o  Whenever the Global (G) bit is set in the BRI, the Acknowledge (A)
      bit MUST be set to request the mobile access gateway to send a
      Binding Revocation Acknowledgement upon receipt of the BRI.

   o  The packet MUST contain the Mobile Node Identifier, MN-ID, option
      which contains the mobile node's NAI that was used in the proxy
      Binding Update during the mobile node registration.




Muhanna, et al.          Expires August 2, 2009                [Page 21]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   o  If the Mobile Node Identifier, MN-ID, is registered in more than
      one of the mobile node's BCE and the LMA does NOT need to revoke
      all of the mobile node's bindings, the packet MUST contain another
      identifier to uniquely identify the mobile node binding(s) that is
      being revoked, e.g., at least one Home Network Prefix option which
      contains the mobile node's registered HNP for the binding being
      revoked.

   o  The care-of address for the binding MAY be used as the destination
      address in the packet's IPv6 header, unless an Alternate Care-of
      Address mobility option is included in the Binding Revocation
      Indication message.


   The Acknowledge (A) bit in the Binding Revocation Indication requests
   the mobile access gateway to return a Binding Revocation
   Acknowledgement in response to this Binding Revocation Indication.
   As described in Section 7.3, the LMA SHOULD retransmit this BRI to
   the MAG before deleting the mobile node IP tunnel to the mobile
   access gateway until it receives a matching Binding Revocation
   Acknowledgement or the BRIMaxRetransmitNumber is reached.  The local
   mobility anchor MAY delete the mobile node(s) IP tunnel immediately
   after sending the Binding Revocation Indication and before receiving
   the BRA message.

   When the local mobility anchor sends a Binding Revocation Indication
   to the mobile access gateway to remove a specific binding and the
   Acknowledge (A) bit is set in the BRI, the local mobility anchor sets
   a flag in the mobile node proxy BCE to indicate that revocation is in
   progress and starts the MINDelayBRIs timer.  The local mobility
   anchor SHOULD maintain the mobile node proxy BCE in this state until
   it receives a Binding Revocation Acknowledgement or the
   BRIMaxRetransmitNumber is reached.  In the case when the local
   mobility anchor sets the Revocation Trigger field to a value which
   indicate inter-MAG handover, the local mobility anchor MAY switch the
   mobile node IP tunnel to the target mobile access gateway before
   sending a Binding Revocation Indication to the sources mobile access
   gateway.

   In a race condition case, the local mobility anchor may receive a PBU
   from the mobile access gateway while the mobile node's proxy BCE has
   the revocation in progress flag set, the LMA should handle this case
   based on the reason for sending the Binding Revocation Indication
   message and its local policy.  In this case, if the LMA accepts the
   PBU, it needs to update the mobile node proxy BCE accordingly, e.g.
   removing the revocation in progress flag.

   When the local mobility anchor needs to revoke all mobile nodes proxy



Muhanna, et al.          Expires August 2, 2009                [Page 22]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   BCE that are registered with the local mobility anchor and hosted at
   the mobile access gateway, the LMA MUST set the Global (G) bit and
   the value of the Revocation Trigger field to "Per-Peer Policy".  In
   this case, the LMA MUST NOT include any mobility options in the BRI.

   When the LMA needs to revoke all mobile nodes proxy BCE that belong
   to a specific realm, e.g. @companyabc.com, and are registered with
   the LMA and hosted at the MAG, the local mobility anchor MUST set the
   Global (G) bit and the value of the Revocation Trigger field to
   "Revoking Node Local Policy".  In this case, the local mobility
   anchor MUST include a mobility option to identify the impacted
   bindings, e.g.  MN-ID option with a wildcard NAI, e.g.
   *@companyabc.com, to identify all the mobile nodes BCEs that need to
   be removed.

   When the mobile node is registered with multiple Home Network
   Prefixes for the same proxy care-of address, the local mobility
   anchor SHOULD include a HNP option for each registered HNP in the
   BRI.  Alternatively, the LMA MAY include only the mobile node
   identifier, MN-ID, option in the BRI to indicate to the mobile access
   gateway to remove all bindings of the specified mobile node NAI in
   the MN-ID option.

   When the mobile node is registered with an IPv4 proxy home address in
   addition to the Home Network Prefix where both of the IPv4 pHoA and
   HNP are bound to the same proxy CoA, the local mobility anchor MAY
   revoke the mobile node IPv4 proxy HoA binding to the current mobile
   node proxy CoA while maintaining the mobile node binding of the HNP
   to its current pCoA as part of the mobile node BCE.  In this case, if
   the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the
   LMA MUST send a BRI message following the procedure in Section 7.1
   and the following rules:

   o  The Acknowledge (A) bit MUST be set in the BRI to request the MAG
      to send a BRA message.

   o  The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to
      indicate that only the IPv4 home address binding is being revoked.

   o  The IPv4 Home Address option MUST be included with the mobile
      node's registered IPv4 home address that is being released in
      addition to the MN-ID option.

   o  The mobile node Home Network Prefix option MUST NOT be included.

   o  The Revocation Trigger field MUST be set to an appropriate value,
      e.g.  "IPv4 Address Lease Expired".




Muhanna, et al.          Expires August 2, 2009                [Page 23]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


9.1.2.  Receiving Binding Revocation Acknowledgement

   When the local mobility anchor receives a packet carrying a valid
   Binding Revocation Acknowledgement that was successfully processed as
   in Section 7.2 and if the mobile node BCE is in the state of
   Revocation in progress, the local mobility anchor SHOULD examine the
   Status field before clearing the mobile node related resources as
   follows:

   o  If the Status field indicates that the BRI was processed
      successfully, the local mobility anchor delete the MINDelayBRIs
      timer and the mobile node proxy bindings and all associated
      resources.

   o  If the Status field indicates partial success value or MN binding
      does not exist, the local mobility anchor SHOULD examine mobility
      options that are included in the Binding Revocation
      Acknowledgement, if any, before deleting the MINDelayBRIs timer
      and the mobile node associated proxy bindings and all related
      resources.  It is based on the LMA local policy how to handle the
      mobile node BCE(s) that the mobile access gateway indicated it
      failed the revocation procedure, however, the LMA MAY log the
      event.


9.2.  Binding Revocation Responder

9.2.1.  Receiving Binding Revocation Indication

   When the local mobility anchor receives a packet carrying a Binding
   Revocation Indication that was successfully processed as in
   Section 7.2, the local mobility anchor SHOULD in addition process the
   message as follows:

   o  Binding Revocation Indication is formatted as in Section 6.1 and
      if the (P) bit is set, the local mobility anchor MUST validate
      that all impacted binding(s) have the proxy binding flag set.

   o  If the Global (G) bit is set, the Proxy (P) bit MUST be set and
      the BRI SHOULD contain the mobile access gateway ID in the MN-ID
      option.  The local mobility anchor MUST verify that the identified
      mobile access gateway as per the value in the MN-ID option is
      authorized to use the Per-Peer Global bindings revocation.  The
      mechanism the LMA uses to verify the MAG authorization is out of
      scope of this document.






Muhanna, et al.          Expires August 2, 2009                [Page 24]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   o  If the Global (G) bit is set and only the mobile node identifier,
      MN-ID, option is included, the local mobility anchor MUST revoke
      all mobile nodes bindings which proxy CoA is the one used as the
      source of the IPv6 packet that carried the BRI.  However, if one
      or more Alternate Care-of Address options are included in addition
      to the mobile node identifier option in the BRI message, the local
      mobility anchor MUST revoke all mobile nodes bindings which proxy
      Care-of Address is one of the Care-of.

   o  The LMA identifies all impacted mobile nodes bindings and if the
      Acknowledgement (A) bit is set, the local mobility anchor MUST
      send a Binding Revocation Acknowledgement following Section 9.2.2
      using the appropriate status code.

   o  If the Global (G) bit is NOT set, the local mobility anchor MUST
      use the included mobility options to identify the impacted mobile
      node binding as follows:

      1.  If only the mobile node identifier, MN-ID, option is included,
          the local mobility anchor MUST revoke all bindings for this
          mobile node which use the specified mobile node NAI.

      2.  If the mobile node identifier, MN-ID, and the Home Network
          Prefix option are included, the local mobility anchor MUST
          only remove the specified proxy binding.

      3.  If the mobile node identifier, MN-ID, option and more than one
          Home Network Prefix options are included, the local mobility
          anchor MUST remove all bindings which are referenced by these
          multiple Home Network Prefixes for the specified mobile node
          NAI.


   The Revocation Trigger field value in the received Binding Revocation
   Indication could be used by the local mobility anchor to log an event
   or update some local parameters which tracks the state of the peer
   mobile access gateway.

9.2.2.  Sending Binding Revocation Acknowledgement

   When the local mobility anchor receive a valid Binding Revocation
   Indication with the (A) bit set and after processing the BRI message,
   the local mobility anchor sends a packet to the mobile access gateway
   containing a Binding Revocation Acknowledgement following the process
   in Section 7.1 and the following:






Muhanna, et al.          Expires August 2, 2009                [Page 25]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   o  If the (P) bit was set in the received Binding Revocation
      Indication, the local mobility anchor MUST set the (P) bit in the
      BRA.

   o  If the Global (G) bit was set in the received BRI, the local
      mobility anchor MUST set the (G) bit in the Binding Revocation
      Acknowledgement.

   o  If the IPv4 HoA Binding Only (V) bit was set in the received BRI,
      the local mobility anchor MUST set the (V) bit in the Binding
      Revocation Acknowledgement.

   o  The local mobility anchor MUST set the status field to a valid
      code that reflects the processing of the received Binding
      Revocation Indication.  If the mobile access gateway is not
      authorized to use the Per-Peer Global revocation feature, the LMA
      MUST set the status field to (Global Revocation NOT Authorized).

   o  In the case that one of the bindings identified in the received
      BRI message has already been released before receiving the BRI,
      the LMA MAY set the status field to partial success and in this
      case it MAY include the mobile node identifier or the Home Network
      Prefix option to identify the binding(s) that failed revocation.

   o  The destination IP address of the IPv6 packet of the Binding
      Revocation Acknowledgement is set to the source IP address of the
      received BRI.



10.  Mobile Access Gateway Operation

10.1.  Binding Revocation Responder

10.1.1.  Receiving Binding Revocation Indication

   Upon receiving a packet carrying a Binding Revocation Indication, the
   mobile access gateway MUST validate the packet according to
   Section 7.2 and the following:

   o  BRI MUST be formatted as in Section 6.1 and the (P) bit is set.

   o  If the Acknowledgement (A) bit in the received BRI is set, the
      mobile access gateway MUST send a Binding Revocation
      Acknowledgement following Section 10.1.2 using the appropriate
      status value.





Muhanna, et al.          Expires August 2, 2009                [Page 26]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   o  If the Global (G) bit is set and the Revocation Trigger field is
      set to "Per-Peer policy", the mobile access gateway identifies all
      bindings that are registered at the LMA and hosted at the MAG.
      This Binding Revocation Indication does not include any other
      mobility options.  In this case, the MAG MUST send a BRA with the
      appropriate status code to the LMA.

   o  If the Global (G) bit is set and the Revocation Trigger field is
      set to "Revoking Node Local Policy", the MAG MUST identify all
      bindings that are registered at the LMA and hosted at the MAG
      using the mobility option(s) included in the BRI.  This Binding
      Revocation Indication SHOULD include at least the MN-ID option,
      e.g. with a wild card NAI.  In this case, the MAG MUST send a BRA
      with the appropriate status code to the LMA.

   o  If the Global (G) bit is set and the Revocation Trigger field is
      set to "Revoking Node Local Policy", and no mobility options are
      included in the Binding Revocation Indication message or the MAG
      is not able to identify the impacted mobile nodes bindings based
      on the included mobility options, the MAG MUST treat this as an
      error scenario.  In this case, the MAG SHOULD send a Binding
      Revocation Acknowledgement message with status "CAN NOT Identify
      Binding".

   o  If the Revocation Trigger field value in the received Binding
      Revocation Indication message indicates an inter-MAG handover and
      the (A) bit is set, the MAG use the mobility option(s) included in
      the BRI message to identify the mobile node binding.  The mobile
      access gateway MAY validate that the mobile node is no longer
      attached to the mobile access gateway before sending a successful
      Binding Revocation Acknowledgement message to the LMA.  However,
      if the Revocation Trigger field is set to "Inter-MAG - Unknown
      Handoff" and the (A) bit is set, the MAG MUST validate that the
      mobile node is no longer attached to the MAG before sending a
      successful BRA message and deleting the resources associated with
      the mobile node binding.  Otherwise, if the MAG verified that the
      MN is still attached, the MAG MUST set the status field in the BRA
      to "Revocation failed - MN is attached".

   o  If the IPv4 HoA Binding Only (V) bit in the received BRI message
      is set, the MAG uses the MN-ID option to identify the mobile node
      binding entry in the BUL.  The MAG MUST verify that the IPv4
      address included in the IPv4 Home Address option in the received
      BRI is the same as the IPv4 proxy HoA that is assigned to the
      mobile node.  After the MAG successfully validates the received
      IPv4 home address as the mobile node IPv4 HoA, the MAG MUST
      consider this as an indication to release the mobile node IPv4
      proxy HoA binding to the mobile node current proxy CoA ONLY.



Muhanna, et al.          Expires August 2, 2009                [Page 27]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


      Consequently, the MAG MUST continue to maintain the mobile node
      IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA
      as part of the mobile node binding in the BUL entry and release
      all resources associated with the MN IPv4 proxy HoA binding to the
      MN pCoA.  In this case, the MAG MUST send a BRA message with the
      status field is set to success.  On the other hand, if the MAG is
      able to identify the mobile node binding using the MN-ID but
      failed to identify the received IPv4 proxy HoA, the MAG MUST send
      a BRA with status field is set to "IPv4 HoA Binding Does NOT
      Exist".

   The Revocation Trigger field value in the received BRI could be used
   by the mobile access gateway to define what actions the MAG could do
   to inform the mobile node that its IP connectivity to the current HNP
   has been terminated. e.g. if the Revocation Trigger field is set to
   "Administrative Reason", the mobile access gateway may send a RA
   message after setting the Home Network Prefix lifetime to zero.

10.1.2.  Sending Binding Revocation Acknowledgement

   When the mobile access gateway receive a valid Binding Revocation
   Indication with the (A) bit set and after processing the BRI message,
   the mobile access gateway sends a packet to the local mobility anchor
   containing a Binding Revocation Acknowledgement according to the
   procedure in Section 7.1 and the following:

   o  The mobile access gateway MUST set the (P) bit in the Binding
      Revocation Acknowledgement if it is set in the received BRI.

   o  If the Global (G) bit was set in the received BRI, the mobile
      access gateway MUST set the (G) bit in the Binding Revocation
      Acknowledgement.

   o  If the IPv4 HoA Binding Only (V) bit was set in the received BRI,
      the mobile access gateway MUST set the (V) bit in the Binding
      Revocation Acknowledgement.

   o  The mobile access gateway MUST set the status field to a valid
      code that reflects the processing of the received Binding
      Revocation Indication.

   o  In the case that one or more of the bindings identified in the
      received BRI message has already been released before receiving
      the BRI, the mobile access gateway MAY set the status field to
      partial success and in this case it MAY include the mobile node
      identifier, MN-ID, or the Home Network Prefix option to identify
      the binding(s) that failed to be removed as part of the revocation
      procedure.



Muhanna, et al.          Expires August 2, 2009                [Page 28]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   o  The destination IP address of the IPv6 packet of the Binding
      Revocation Acknowledgement is set to the source IP address of the
      received Binding Revocation Indication.


10.2.  Binding Revocation Initiator

10.2.1.  Sending Binding Revocation Indication

   The mobile access gateway could send a Binding Revocation Indication
   message to indicate the termination of multiple mobile node bindings,
   e.g., when using the global revocation with the Global (G) bit is
   set.  In this case when an event occurs which requires the mobile
   access gateway to inform the LMA to terminate all mobile nodes
   bindings that are registered at the local mobility anchor and the
   mobile access gateway, the mobile access gateway sends a Binding
   Revocation Indication message following Section 7.1 and the
   following:

   o  The Acknowledge (A) bit MUST be set in the Binding Revocation
      Indication to request the local mobility anchor to send a Binding
      Revocation Acknowledgement upon receipt of the BRI.

   o  The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation
      Indication to indicate that bindings that being revoked is a proxy
      Mobile IPv6 binding.

   o  The Global (G) bit MUST be set and the Revocation Trigger contains
      a value of "Per-Peer Policy" in the Binding Revocation Indication
      to request the LMA to remove all Per-Peer bindings that are
      registered with the LMA and hosted at this MAG.  In this case, the
      MN-ID option MUST be included in the BRI and contains the mobile
      access gateway identity.  In this case the mobile access gateway
      MAY include one or more Alternate Care-of Address option(s).  The
      Alternate Care-of Address option(s) include the proxy Care-of
      address(es) which their bindings are being impacted by this BRI
      message.

   o  The mobile access gateway address MAY be used as the Source
      Address in the packet's IPv6 header.


   The Acknowledge (A) bit in the Binding Revocation Indication requests
   the local mobility anchor to return a BRA in response to this Binding
   Revocation Indication.  As described in Section 7.3, the mobile
   access gateway SHOULD retransmit this BRI to the local mobility
   anchor until it receives a matching BRA or the BRIMaxRetransmitNumber
   is reached.  The mobile access gateway MAY delete the mobile nodes IP



Muhanna, et al.          Expires August 2, 2009                [Page 29]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   tunnels immediately after sending the Binding Revocation Indication
   before receiving a BRA message from the LMA.

10.2.2.  Receiving Binding Revocation Acknowledgement

   When the mobile access gateway receives a packet carrying a valid
   Binding Revocation Acknowledgement that was successfully processed
   according to Section 7.2, the mobile access gateway MUST process the
   BRA as per the followings:

   o  When the mobile access gateway receives a packet carrying a valid
      Binding Revocation Acknowledgement and the Global (G) and Proxy
      MIPv6 (P) bits are set and the mobile nodes BCEs are in the state
      of Revocation in Progress, the mobile access gateway SHOULD
      examine the Status field as follows:

   o  If the Status field indicates that the Binding Revocation
      Indication was processed successfully, the mobile access gateway
      delete the MINDelayBRIs timer and the mobile nodes proxy bindings
      and all associated resources.

   o  If the Status field indicates (Global Revocation NOT Authorized),
      the mobile access gateway is not authorized to participate in a
      Per-Peer Global Revocation.  The mobile access gateway SHOULD NOT
      retry sending a Binding Revocation Indication with the Global (G)
      bit is set to the same local mobility agent.  The mobile access
      gateway should raise an alarm or log an event to indicate this
      rejection.


11.  Mobile Node Operation

11.1.  Receiving Binding Revocation Indication

   Upon receiving a packet carrying a Binding Revocation Indication, the
   mobile node MUST validate the packet according to Section 7.2 and the
   following tests:

   o  The mobile node MUST verify that the IP address in the type 2
      routing header is its Home Address and that its Binding Update
      List contains an entry for that Home Address.  If one of the
      tests, fails the mobile node SHOULD silently discard the received
      BRI message.

   o  If the Acknowledgement (A) bit is set in the Binding Revocation
      Indication and its Binding Update List contains an entry for the
      IP address in the type 2 routing header, the mobile node MUST send
      a Binding Revocation Acknowledgement.  However, in all other cases



Muhanna, et al.          Expires August 2, 2009                [Page 30]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


      when the (A) bit is set in the BRI, the mobile node SHOULD send a
      Binding Revocation Acknowledgement.  In all cases, the mobile node
      MUST follow Section 11.2 and send a BRA using the appropriate
      status code.

   o  If the IPv4 HoA Binding Only (V) bit is set in the received BRI
      message, the MN MUST verify that there is an IPv4 HoA option in
      the received BRI and the IPv4 address included in the IPv4 Home
      Address option is the same as its IPv4 HoA that is assigned to the
      mobile node.  If this verification is successful, the MN MUST
      consider this BRI as an indication to release the mobile node IPv4
      HoA binding to its current Care-of Address ONLY.  Consequently,
      the MN MUST continue to maintain its IPv6 HoA binding to the
      current CoA as part of the mobile node binding in the BUL entry
      and release all resources associated with the MN IPv4 HoA binding.
      In this case, the MN MUST send a BRA message with the status field
      is set to success.  On the other hand, if the IPv4 HoA option was
      NOT included in the received BRI with the (V) bit set, the MN
      SHOULD send a BRA message with the status field set to "IPv4 HoA
      Option Required".  Additionally, if the verification received IPv4
      HoA in the IPv4 HoA option is NOT the one assigned to the MN, the
      MN SHOULD send a BRA with the status field is set to "IPv4 HoA
      Binding Does NOT Exist".

   o  The mobile node MUST verify that the (P) bit in the Binding
      Revocation Indication is NOT set.  If the (P) bit is set, the
      mobile node MUST silently discard the Binding Revocation
      Indication message.

   o  If the mobile node has registered multiple care-of addresses with
      its home agent, the mobile node MUST verify which binding is being
      revoked by examining the content of the BRI message.  If the
      mobile node received a Binding Revocation Indication with a single
      or more than one Binding ID options and its home address is
      included in the type 2 routing header, the mobile node MUST
      consider all of the care-of address(es) binding(s), identified in
      the Binding ID options, with this home address are being revoked.

   o  If the mobile node has multi Care-of Addresses bindings with its
      home agent and received a Binding Revocation Indication, without
      any Binding ID option included and its home address was included
      in the type 2 routing header, the mobile node MUST consider all of
      its registered care-of addresses bindings with this home address
      are being revoked.


   The Revocation Trigger field value in the received Binding Revocation
   Indication could be used by the mobile node to define what action the



Muhanna, et al.          Expires August 2, 2009                [Page 31]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   mobile node could do to be able to register again and receive its IP
   mobility service, e.g. contacting its home operator.

11.2.  Sending Binding Revocation Acknowledgement

   When the mobile node receives a Binding Revocation Indication from
   its home agent, the mobile node processes the received BRI as in
   Section 11.1.  If the mobile node is required to send a BRA message
   in response to the received BRI, the mobile node sends a packet to
   its home agent containing a Binding Revocation Acknowledgement
   according to the procedure in Section 7.1 and the following:

   o  The mobile node MUST set the status field to an appropriate value.
      The mobile node sets the status field to success to reflect that
      it has received the Binding Revocation Indication and acknowledge
      that its IP connectivity with its home agent has been revoked.

   o  The destination IP address of the IPv6 packet of the Binding
      Revocation Acknowledgement is set to the source IP address of the
      received IPv6 packet of the Binding Revocation Indication.  The
      Mobile Node MUST include its home address in the Home Address
      Destination Option.


12.  Protocol Configuration Variables

   Any mobility entity which is allowed to invoke the binding revocation
   procedure by sending a Binding Revocation Indication message SHOULD
   allow the following variables to be configured.

   BRI Maximum Number of Retries (BRIMaxRetriesNumber)

      This variable specifies the maximum Number of times a mobility
      entity can retransmit a Binding Revocation Indication message
      before receiving a Binding Revocation Acknowledgement message.
      The default value for this parameter is 1.

   Minimum Delay Between BRI messages (MINDelayBRIs)

      This variable specifies the delay time in seconds before the
      revoking mobility entity retransmits a BRI message.  The default
      is 1 second but not less than 0.5 seconds.


13.  IANA Considerations

   This document defines two new messages BRI and BRA, as described in
   Section 6.1 and Section 6.2 by using Binding Revocation types of 1



Muhanna, et al.          Expires August 2, 2009                [Page 32]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   and 2 of the Binding Revocation Message which is defined in in
   Section 6 and uses a MH type <IANA-TBD>.  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, Arnaud Ebalard, and Patrick Stupar for their
   review and comments of this draft and all colleagues who have
   supported the advancement of this draft effort.


16.  References

16.1.  Normative References

   [ID-DSMIP6]
              Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
              Routers", draft-ietf-mext-nemo-v4traversal-07 (work in
              progress), December 2008.

   [ID-MCoA]  Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
              "Multiple Care-of Addresses Registration",
              draft-ietf-monami6-multiplecoa-11 (work in progress),
              January 2009.

   [ID-PMIP6-IPv4]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
              (work in progress), January 2009.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate



Muhanna, et al.          Expires August 2, 2009                [Page 33]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


              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.


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











Muhanna, et al.          Expires August 2, 2009                [Page 34]

Internet-Draft    Binding Revocation for IPv6 Mobility      January 2009


   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
   Juniper Networks
   1194 North Mathilda Avenue
   Sunnyvale, CA  94089
   USA

   Email: pyegani@juniper.net


























Muhanna, et al.          Expires August 2, 2009                [Page 35]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/