draft-ietf-mext-binding-revocation-03.txt   draft-ietf-mext-binding-revocation-04.txt 
Network Working Group A. Muhanna Network Working Group A. Muhanna
Internet-Draft M. Khalil Internet-Draft M. Khalil
Intended status: Standards Track Nortel Intended status: Standards Track Nortel
Expires: August 2, 2009 S. Gundavelli Expires: September 25, 2009 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
January 29, 2009 March 24, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-03.txt draft-ietf-mext-binding-revocation-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2009. This Internet-Draft will expire on September 25, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
This document defines the revocation semantics for terminating a This document defines a binding revocation mechanism to terminate a
mobile node's mobility session and associated resources. These mobile node's mobility session and the associated resources. These
semantics are generic enough and can be used by mobility entities in semantics are generic enough and can be used by mobility entities in
the case of Client Mobile IPv6 and its extensions. This mechanism the case of Mobile IPv6 and its extensions. This mechanism allows
allows the mobility entity which initiates the revocation procedure the mobility entity which initiates the revocation procedure to
to request its corresponding one to terminate either one, multiple or request its corresponding one to terminate either one, multiple or
all specified binding cache entries. all specified binding cache entries.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4
2.1. Conventions used in this document . . . . . . . . . . . . 4 2.1. Conventions used in this document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4
3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5
3.2. Client MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . 6 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6
3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 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. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8
3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding
3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 10 Revocation . . . . . . . . . . . . . . . . . . . . . . 8
3.4.3. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 9
4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Exchanging Binding Revocation Messages over an IPv4 5. Binding Revocation Messages over IPv4 Transport Network . . . 10
Transport Network . . . . . . . . . . . . . . . . . . . . . . 10 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10
6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11 6.1. Binding Revocation Indication Message . . . . . . . . . . 11
6.1. Binding Revocation Indication Message . . . . . . . . . . 12 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14
6.2. Binding Revocation Acknowledgement Message . . . . . . . . 15
7. Binding Revocation Process Considerations . . . . . . . . . . 17 7. Binding Revocation Process Considerations . . . . . . . . . . 17
7.1. Sending Binding Revocation Messages . . . . . . . . . . . 17 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 17
7.2. Receiving Binding Revocation Messages . . . . . . . . . . 18 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 18
7.3. Retransmission of Binding Revocation Indication . . . . . 18 7.3. Retransmission of Binding Revocation Indication . . . . . 19
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19
8.1. Sending Binding Revocation Indication . . . . . . . . . . 19 8.1. Sending Binding Revocation Indication . . . . . . . . . . 19
8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20
9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 21 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 21
9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 21 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 21
9.1.1. Sending Binding Revocation Indication . . . . . . . . 21 9.1.1. Sending Binding Revocation Indication . . . . . . . . 21
9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 24 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23
9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 24 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 24
9.2.1. Receiving Binding Revocation Indication . . . . . . . 24 9.2.1. Receiving Binding Revocation Indication . . . . . . . 24
9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 25 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 25
10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26
10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26
10.1.1. Receiving Binding Revocation Indication . . . . . . . 26 10.1.1. Receiving Binding Revocation Indication . . . . . . . 26
10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 28 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 28
10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 29 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 29
10.2.1. Sending Binding Revocation Indication . . . . . . . . 29 10.2.1. Sending Binding Revocation Indication . . . . . . . . 29
10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 30 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 29
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 30 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 30
11.1. Receiving Binding Revocation Indication . . . . . . . . . 30 11.1. Receiving Binding Revocation Indication . . . . . . . . . 30
11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 32 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 32
12. Protocol Configuration Variables . . . . . . . . . . . . . . . 32 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 32
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 14. Security Considerations . . . . . . . . . . . . . . . . . . . 34
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 33 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . . 34 16.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
In the case of Mobile IPv6 and for administrative reason, sometimes In the case of Mobile IPv6 and for administrative reason, sometimes
it becomes necessary to inform the mobile node that its registration 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 has been revoked and the mobile node is no longer able to receive IP
mobility service using its Home Address. In some networks where mobility service using its Home Address. A similar Mobile IPv4
Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 registration revocation mechanism [RFC3543] has been specified by
registration revocation mechanism has been specified [RFC3543]. IETF for providing a revocation mechanism for sessions that were
established using Mobile IPv4 registration [RFC3344].
This document defines the semantics of the revocation mechanism of a This document specifies a binding revocation mechanism that can be
mobile node registration binding, which could have been established used to revoke a mobile node's mobility session(s). The same
using a Client Mobile IPv6 or any of its extensions, e.g. Proxy mechanism can be used to revoke bindings created using Mobile IPv6
Mobile IPv6 signaling. The proposed revocation mechanism uses a new [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6
MH type <IANA-TBD> for revocation signaling which is applicable to [RFC5213]. The proposed revocation mechanism uses a new MH type
Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used <IANA-TBD> for revocation signaling which is applicable to Mobile
by any two IP mobility entities. As an example, this mechanism IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any
allows a local mobility anchor, involved in providing IP mobility two IP mobility entities. As an example, this mechanism allows a
services to a mobile node, to notify the mobile access gateway of the local mobility anchor, involved in providing IP mobility services to
termination of a mobile node binding registration. In another a mobile node, to notify the mobile access gateway of the termination
example, a mobile access gateway can use this mechanism to notify its of a mobile node binding registration. In another example, a mobile
local mobility anchor peer with a bulk termination of all or a subset access gateway can use this mechanism to notify its local mobility
of Proxy Mobile IPv6 bindings that are registered with the local anchor peer with a bulk termination of all or a subset of Proxy
mobility anchor and currently being served by the mobile access Mobile IPv6 bindings that are registered with the local mobility
gateway. anchor and currently being served by the mobile access gateway.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions used in this document 2.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Terminology 2.2. Terminology
All the general mobility related terminology and abbreviations are to All the general mobility related terminology and abbreviations are to
be interpreted as defined in Mobile IPv6 specification [RFC3775] and be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile
Proxy Mobile IPv6 specification [RFC5213]. IPv6 [RFC5213] specifications.
3. Binding Revocation Protocol and Use Cases Overview 3. Binding Revocation Protocol and Use Cases Overview
This specification defines a binding revocation mechanism where a This specification specifies a binding revocation mechanism where a
mobility node can communicate to the mobile node or another mobility mobility node can communicate to the mobile node or another mobility
node the termination of the mobile node registration binding. The node the termination of the mobile node registration binding. The
following subsections describe the protocol overview and applicable following subsections describe the protocol overview and applicable
use cases. use cases.
3.1. Binding Revocation Protocol 3.1. Binding Revocation Protocol
In the case of Client Mobile IPv6, the revocation procedure can be In the case of Mobile IPv6, if the home network decides to terminate
initiated by the home agent. If the home network decides to the service of the mobile node, the home agent sends a Binding
terminate the service of the mobile node, the home agent sends a Revocation Indication (BRI) message to the mobile node. The home
Binding Revocation Indication (BRI) message to the mobile node. The agent includes the HoA in the Type 2 routing header as specified in
home agent includes the HoA in the type 2 routing header as specified [RFC3775] to indicate the impacted mobile node binding. In the case
in [RFC3775] to indicate the impacted mobile node binding. When the of DSMIPv6 [ID-DSMIP6], the home agent may include the IPv4 Home
mobile node receives a BRI message with its HoA included and the Address Option with the mobile node assigned home IPv4 address.
Additionally, if the mobile node registered multiple care-of
addresses [ID-MCoA], the home agent includes the Binding ID option(s)
in the Binding Revocation Indication message to identify which
binding is being revoked. When the mobile node receives a BRI
message with its HoA included in the Type 2 routing header and the
Acknowledge (A) bit is set, the mobile node responds by sending a Acknowledge (A) bit is set, the mobile node responds by sending a
Binding Revocation Acknowledgement (BRA) message. 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 Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation
procedure can be initiated by the local mobility anchor by sending a procedure can be initiated by the local mobility anchor by sending a
BRI message to communicate the termination of a mobile node BRI message to communicate the termination of a mobile node
registration binding to the mobility access gateway. In this case, registration binding to the mobility access gateway. In this case,
the local mobility anchor includes the mobile node Home Network the local mobility anchor includes the mobile node Home Network
Prefix option [RFC5213] and the MN-ID option [RFC4283] to indicate to Prefix option [RFC5213] and the MN-ID option [RFC4283] to indicate to
the mobility access gateway the identity of the PMIPv6 binding that the mobility access gateway the identity of the PMIPv6 binding that
needs to be terminated. When the mobility access gateway receives needs to be terminated. When the mobility access gateway receives
the BRI message with the (A) bit set, the mobility access gateway the BRI message with the (A) bit set, the mobility access gateway
responds to the local mobility anchor by sending a BRA message. responds to the local mobility anchor by sending a BRA message.
On the other hand, the MAG usually sends a de-registration message by 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 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 the termination of the PMIPv6 mobile node binding registration. In
this case, the MAG includes the MN HNP option, the MN-ID option and 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 all other required mobility options as per [RFC5213] in order for the
LMA to identify the mobile node PMIPv6 binding. However, in the case LMA to identify the mobile node PMIPv6 binding. Additionally, in the
when the mobility access gateway communicates a bulk termination of case when the mobility access gateway communicates a bulk termination
PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A) 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 bits set and includes the MAG identity in the MN-ID option. When the
the LMA receives such BRI message, it ensures that the mobility LMA receives such BRI message, it ensures that the mobility access
access gateway is authorized to send such bulk termination message gateway is authorized to send such bulk termination message and then
and then process the BRI message accordingly. If the local mobility process the BRI message accordingly. If the local mobility anchor
anchor processes the BRI message successfully and since the (A) bit processes the BRI message successfully, the LMA responds to the
is set, the LMA responds to the mobile access gateway by sending the mobile access gateway by sending the BRA message.
BRA message. Additionally, the initiator of the binding revocation
procedure includes an indication in the Revocation Trigger field to
indicate to the receiving node the cause for the revocation
procedure.
3.2. Client MIPv6 and DSMIP6 Use Case In any of the above cases, the initiator of the binding revocation
procedure, e.g., HA, LMA, MAG, uses the Revocation Trigger field in
the Binding Revocation Indication message to indicate to the
receiving node the reason for initiating the revocation procedure.
Binding revocation mechanism is applicable to Client Mobile IPv6 and 3.2. MIPv6 and DSMIP6 Use Case
DSMIPv6 session(s) when the home agent needs to inform the mobile
node that its binding registration has been revoked, e.g. for an Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6
administrative reason. This mechanism enables the home domain to session(s) when the home agent needs to inform the mobile node that
dynamically allow the user to act upon the revocation message in its binding registration has been revoked, e.g. for an administrative
order to recover its interrupted mobile IPv6 services. 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 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 mobile node that its current mobile IPv6 binding has been revoked and
it no longer can receive IP mobility service. The home agent it no longer can receive IP mobility service. The home agent
includes the mobile node home address in Type 2 routing header as includes the mobile node home address in Type 2 routing header as
used in [RFC3775] and sets the Revocation Trigger field to a proper used in [RFC3775] and sets the Revocation Trigger field to a proper
value, e.g. Administrative Reason. In the case of DSMIPv6 session, value, e.g. Administrative Reason. In the case of DSMIPv6 session,
the home agent may additionally include the mobile node assigned IPv4 the home agent may additionally include the mobile node assigned IPv4
Home Address in the IPv4 Home Address Option. When the mobile node Home Address in the IPv4 Home Address Option. When the mobile node
receives the BRI message, it sends a BRA message as described in receives the BRI message, it sends a BRA message as described in
Section 11.2 to the home agent. Figure 1 illustrates the message Section 11.2 to the home agent. Figure 1 illustrates the message
sequencing when home agent revokes a mobile node binding sequencing when home agent revokes a mobile node binding
registration. registration.
MN HA MN HA
| | | |
| HoA in Type 2 Hdr + BRI [seq.#, A bit] | | HoA in Type 2 Hdr |
|<------------------------------------------| |<<<------------... + ...-----------------|
| | | BRI [seq.#, A bit, Revocation Trigger] |
| | | |
| | | |
| HoA in Destination Option BRA[seq.#] | | BRA (HoA in Dest. Option)[seq.#, Status] |
|------------------------------------------>| |---------------------------------------->>>|
| | | |
| | | |
Figure 1: Home Agent Revokes a Mobile Node Binding Registration Figure 1: Home Agent Revokes a Mobile Node Binding Registration
3.3. Multi-Care of Addresses (Monami6) Use Case 3.3. Multi-Care of Addresses (Monami6) Use Case
In the case of Monami6 protocol, a mobile node is able to register In the case of multiple care-of addresses registration [ID-MCoA], the
multiple care-of addresses for the same home address [ID-MCoA]. home agent maintains different binding for each pair of care-of
Binding revocation mechanism is applicable to Monami6 when the HA address and home address. These bindings are also indexed and
sends a BRI message to revoke a single or more care-of address identified during the mobile node registration using a Binding ID
bindings. mobility option. The HA may revoke one or multiple bindings for the
same mobile node home address.
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 If the home agent revokes a single binding for a mobile node with
node with multiple care-of addresses registration, the home agent multiple care-of addresses registration, the home agent sends a BRI
sends a BRI message to the mobile node with the corresponding BID message to the mobile node with the corresponding BID option
option included and the HoA is in the Type 2 routing header. If the included. If more than one of the mobile node registered care-of
home agent needs to revoke more than one of the mobile node addresses need to be revoked, the home agent includes all the
registered care-of addresses, the home agent includes all the corresponding Binding ID options in the same BRI message. Figure 2
corresponding Binding ID options which reference these care-of illustrates the message flow when the HA revokes two registered
addresses in the same BRI message. Figure 2 illustrates the message Care-of addresses for the same MN in a single BRI 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 HA Binding Cache
================ ================
MN-BID1 [CoA1+HoA] MN-BID1 [CoA1+HoA]
MN HA MN-BID2 [CoA2+HoA] MN HA MN-BID2 [CoA2+HoA]
| | MN-BID3 [CoA3+HoA] | | MN-BID3 [CoA3+HoA]
| BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA] | | MN-BID4 [CoA4+HoA]
|<------------------------------------------| | HoA in Type 2 Hdr |
| | |<----------------- + --------------------|
| BRI [seq.#, A bit, BID1, BID4] |
| | | |
| | | |
| BRA [seq.#, Status] | | BRA (HoA in Dest. Option) [seq.#, Status] |
|------------------------------------------>| |------------------------------------------>|
| | | |
| | | |
Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings
3.3.2. Termination of All Care-of Addresses Bindings Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings
The home agent may revoke all of the mobile node registered bindings, Additionally, the home agent may revoke all of the mobile node
by sending a BRI message without including any BID options while the registered bindings, by sending a BRI message without including any
HoA is included in the Type 2 header. Figure 1 illustrates the BID options while the HoA is included in the Type 2 routing header.
message flow when the home agent revokes all registered Care-of Figure 1 illustrates the message flow when the home agent revokes all
addresses bindings for a MN in a single BRI message. registered Care-of addresses bindings for a MN in a single BRI
message.
3.4. Proxy MIPv6 Use Case 3.4. Proxy MIPv6 Use Case
Since the Mobile node does not participate in the mobility mechanism Since the Mobile node does not participate in the mobility mechanism
in the case of PMIPv6, there are many scenarios where Binding in the case of PMIPv6, there are many scenarios where Binding
Revocation mechanism is needed to clean resources and make sure that Revocation mechanism is needed to clean resources and make sure that
the mobility entities, e.g. MAG and LMA, are always synchronized the mobility entities, e.g. MAG and LMA, are always synchronized
with respect to the status of the existing proxy mobile IPv6 with respect to the status of the existing proxy mobile IPv6
bindings. The binding revocation mechanism is generic enough that bindings. The binding revocation mechanism is generic enough that
can be used in all applicable PMIPv6 scenarios and deployment can be used for all Proxy Mobile IPv6 scenarios that follow [RFC5213]
options. For example, this revocation mechanism is still applicable and [ID-PMIP6-IPv4] specifications.
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 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 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 Section 10.1.2. Similarly, if the LMA receives a BRI message with
(A) bit is set, the LMA responds to the MAG by sending a BRA message. 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 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation
The local mobility anchor may send a BRI message to the mobile access The local mobility anchor may send a BRI message to the mobile access
gateway, hosting a specific proxy mobile IPv6 binding, with the gateway, hosting a specific proxy mobile IPv6 binding, with the
appropriate value in the revocation trigger field to indicate that appropriate value in the revocation trigger field to indicate that
the mobile node binding has been terminated and the MAG can clean up the mobile node binding has been terminated and the MAG can clean up
the applicable resources. When the MAG receives a BRI message, the 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 MAG identifies the respected binding and if the (A) bit was set in
received BRI message, the MAG sends a BRA message to the LMA. 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 this case, the MAG could send a Router Advertisement message to the
MN with the home network prefix lifetime set to zero. MN with the home network prefix lifetime set to zero.
As an example, Figure 3, illustrates the message sequence for As an example, Figure 3, illustrates the message sequence for
revoking a mobile node binding at the source MAG during the MN inter- revoking a mobile node binding at the source MAG during the MN inter-
MAG handoff. During the inter-MAG handoff, the mobile node moves 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 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 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 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 source MAG and upon receiving the PBU from the target MAG, LMA
skipping to change at page 9, line 21 skipping to change at page 9, line 5
clean up the applicable resources reserved for the specified MN clean up the applicable resources reserved for the specified MN
binding. The MAG acknowledges the BRI message by sending a BRA binding. The MAG acknowledges the BRI message by sending a BRA
message to indicate the success or failure of the termination of the message to indicate the success or failure of the termination of the
mobile node binding. mobile node binding.
The process identified above can also be used by the LMA in scenarios The process identified above can also be used by the LMA in scenarios
other than the inter-MAG handoff with the proper revocation trigger other than the inter-MAG handoff with the proper revocation trigger
value to indicate to the peer MAG that a specific proxy mobile IPv6 value to indicate to the peer MAG that a specific proxy mobile IPv6
binding or bindings have been revoked. binding or bindings have been revoked.
sMAG tMAG LMA oldMAG newMAG LMA
| | | | | |
| | PBU | | | PBU |
| |--------------------------->| | |--------------------------->|
| | PBU triggers | | PBU triggers
| | BRI Msg to sMAG | | BRI Msg to oldMAG
| | | | | |
| | PBA | | | PBA |
| |<---------------------------| | |<---------------------------|
| | | | | |
| | | | | |
| BRI [seq.#, R. Trigger, P, A bits, NAI] | | BRI [seq.#, R. Trigger, P, A bits, NAI] |
|<-----------------------------------------| |<-----------------------------------------|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| BRA [seq.#, Status, P bit] | | BRA [seq.#, Status, P bit] |
|----------------------------------------->| |----------------------------------------->|
| | | | | |
| | | | | |
Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff
3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings In addition, the LMA can send a BRI message to indicate that all
bindings which are hosted by the peer MAG and registered with the LMA
The LMA sends a BRI message to indicate that all bindings which are are being revoked by setting the (G) bit as described in
hosted by the peer MAG and registered with the LMA are being revoked Section 9.1.1.
by setting the (G) bit as described in Section 9.1.1.
3.4.3. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings
The mobile access gateway sends a BRI message with the (G) bit is set 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 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. 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 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 specified MAG, the LMA checks if the MAG is authorized to use global
revocations and responds with the appropriate status code by sending revocations and responds with the appropriate status code by sending
a BRA message as in Section 9.2.2. a BRA message as in Section 9.2.2.
4. Security Model 4. Security Model
The binding revocation protocol described here uses the same security 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 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 been used to exchange the corresponding MIPv6 or Proxy MIPv6 BU and
BU and BA when the mobile node binding was created. If IPsec is BA when the mobile node binding was created. If IPsec is used, the
used, the traffic selectors associated with the SP protecting BU and traffic selectors associated with the SPD entry protecting BU and BA
BA MUST be extended to include Binding Revocation Signaling MH type MUST be extended to include Binding Revocation Signaling MH type
<IANA-TBD>. Extending the traffic selectors of the SP in order to <IANA-TBD>. Extending the traffic selectors of the SPD entry in
reuse the SA protecting BU and BA (instead of creating new ones) order to reuse the SA protecting BU and BA (instead of creating new
ensures that those SA will be up and running when the revoking entity ones) ensures that those SA will be up and running when the revoking
needs to send a Binding Revocation Signaling message. entity needs to send a binding revocation signaling message.
Additionally, in the case when the LMA receives a BRI which indicates 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 a bulk termination where the (G) bit is set and the Revocation
that the MAG sending the binding revocation indication message is Trigger field is set to "Per-Peer Policy", the LMA MUST verify that
the MAG sending the binding revocation indication message is
authorized to invoke Global revocation. authorized to invoke Global revocation.
5. Exchanging Binding Revocation Messages over an IPv4 Transport 5. Binding Revocation Messages over IPv4 Transport Network
Network
In some deployments, the network between the MAG and the LMA may only In some deployments, the network between the MAG and the LMA may only
support IPv4 transport. In this case, the Binding Revocation support IPv4 transport. In this case, the Binding Revocation
messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding
Update and Proxy Binding Acknowledgment messages are sent using UDP Update and Proxy Binding Acknowledgment messages are sent using UDP
encapsulation to traverse NATs, then the Binding Revocation messages encapsulation to traverse NATs, then the Binding Revocation messages
are sent using the same UDP encapsulation. The same UDP port that are sent using the same UDP encapsulation. The same UDP port that
was used for the Proxy Binding Update and Proxy Binding was used for exchanging the Proxy Binding Update and Proxy Binding
Acknowledgement messages will also be used when transporting Binding Acknowledgement messages will also be used when transporting Binding
Revocation messages over IPv4 using UDP encapsulation. For more Revocation messages over IPv4 using UDP encapsulation. In other
details on tunneling Proxy Mobile IPv6 signaling messages over IPv4, words, the destination UDP port of the BRI message MUST be set to the
see [ID-PMIP6-IPv4]. source UDP port of the latest successfully processed Proxy Binding
Update message which is already saved in the mobile node BCE. For
more details on tunneling Proxy Mobile IPv6 signaling messages over
IPv4, see [ID-PMIP6-IPv4].
6. Binding Revocation Message 6. Binding Revocation Message
This section defines the Binding Revocation Message format using a MH This section defines the Binding Revocation Message format using a MH
Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding
Revocation Type field defines whether the Binding Revocation message Revocation Type field defines whether the Binding Revocation message
is a BRI or BRA. If the Binding Revocation type field is set to 1, is a BRI or BRA. If the Binding Revocation type field is set to 1,
the Binding Revocation Message is a Binding Revocation Indication the Binding Revocation Message is a Binding Revocation Indication as
message as in Section 6.1. However, if the value is 2, it is a in Section 6.1. However, if the value is 2, it is a Binding
Binding Revocation Acknowledgement message as in Section 6.2. Revocation Acknowledgement message as in Section 6.2.
0 1 2 3 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 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 | | Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | B.R. Type | | | Checksum | B.R. Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. Binding Revocation Message Data . . Binding Revocation Message Data .
skipping to change at page 12, line 24 skipping to change at page 12, line 4
Revocation Message which has a MH type <IANA-TBD> and 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 Revocation Type value of 1. It is used by the revoking mobility node
to inform the receiving mobility entity that the IP mobility service to inform the receiving mobility entity that the IP mobility service
of a specific binding or bindings have been revoked. Binding of a specific binding or bindings have been revoked. Binding
Revocation Indication message is sent as described in Section 8.1, Revocation Indication message is sent as described in Section 8.1,
Section 9.1.1, and Section 10.2.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 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 Revocation Message, the format of the Binding Revocation Message Data
follows the Binding Revocation Indication message as in Figure 5 follows the Binding Revocation Indication message as in Figure 5
0 1 2 3 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 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 | | B.R. Type = 1 | R. Trigger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |P|A|V|G| Reserved | | Sequence # |A|P|V|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Binding Revocation Indication Message Figure 5: Binding Revocation Indication Message
Revocation Trigger Revocation Trigger
8-bit unsigned integer indicating the event which triggered the 8-bit unsigned integer indicating the event which triggered the
revoking node to send the BRI message. The following Revocation revoking node to send the BRI message. The Reserved and Per-MN
Trigger values are currently defined: Revocation Triggers value are less than 128. The per-MN
revocation triggers is used when the BRI message intends to revoke
one or more bindings for the same mobile node. The Global
Revocation Trigger values are greater than 128 and used in the BRI
message with the (G) bit is set for for global revocation. The
following Revocation Trigger values are currently defined:
Reserved and Per-MN Revocation Trigger:
0 Reserved 0 Reserved
1 Unspecified 1 Unspecified
2 Administrative Reason 2 Administrative Reason
3 Inter-MAG Handoff - same Access Types 3 Inter-MAG Handoff - same Access Types
4 Inter-MAG Handoff - different Access Types 4 Inter-MAG Handoff - different Access Types
5 Inter-MAG - Unknown Handoff 5 Inter-MAG - Unknown Handoff
6 Per-Peer Policy 6 User Initiated Session(s) Termination
7 Revoking Node Local Policy 7 Access Network Session(s) Termination
8 User Initiated Session(s) Termination 8 IPv4 HoA Lease Expires
9 Access Network Session(s) Termination 9 Possible Out-of Sync BCE State
10 IPv4 HoA Lease Expires
11 Possible Out-of Sync BCE State
250-255 Reserved For Testing Purposes only 250-255 Reserved For Testing Purposes only
All other values are Reserved All other values are Reserved
Global Revocation Trigger:
128 Per-Peer Policy
129 Revoking Mobility Node Local Policy
Sequence # Sequence #
A 16-bit unsigned integer used by the sending mobility node to A 16-bit unsigned integer used by the sending mobility node to
match a returned Binding Revocation Acknowledgement with this match a returned Binding Revocation Acknowledgement with this
Binding Revocation Indication. Binding Revocation Indication. It could be a random number.
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) Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobility node, e.g. The Acknowledge (A) bit is set by the sending mobility node, e.g.
LMA, HA, or MAG, to request a Binding Revocation Acknowledgement LMA, HA, or MAG, to request a Binding Revocation Acknowledgement
be returned upon receipt of the Binding Revocation Indication as be returned upon receipt of the Binding Revocation Indication as
in Section 8.1, Section 9.1.1, and Section 10.2.1. in Section 8.1, Section 9.1.1, and Section 10.2.1.
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.
IPv4 HoA Binding Only (V) IPv4 HoA Binding Only (V)
The IPv4 HoA Binding Only (V) bit is set by the sending mobility The IPv4 HoA Binding Only (V) bit is set by the sending mobility
node, HA or LMA, to request the receiving mobility entity the node, HA or LMA, to request the receiving mobility entity the
termination of the IPv4 Home Address binding only as in termination of the IPv4 Home Address binding only as in
Section 8.1, and Section 9.1.1. Section 8.1, and Section 9.1.1.
Global (G) Global (G)
The Global (G) bit is set by the sending mobility node, LMA or The Global (G) bit is set by the sending mobility node, LMA or
skipping to change at page 14, line 28 skipping to change at page 14, line 15
the specific binding or bindings that the sending mobility entity the specific binding or bindings that the sending mobility entity
requesting to be revoked. requesting to be revoked.
The following options are valid in a Binding Revocation Indication: The following options are valid in a Binding Revocation Indication:
o Home Network Prefix option [RFC5213]. This option MAY be used 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 when the (P) bit is set. This option MUST be present when the BRI
is used to revoke a single PMIP binding cache entry. is used to revoke a single PMIP binding cache entry.
o Mobile Node Identifier Option [RFC4283]. This option is mandatory o Mobile Node Identifier Option [RFC4283]. This option is mandatory
when the (P) bit is set. Additionally, If the (G) bit is set by when the (P) bit is set. Additionally, if the (G) bit is set by
the mobile access gateway, this option carries the MAG identity. the mobile access gateway, this option carries the MAG identity.
o Binding ID mobility option [ID-MCoA]. This option is mandatory if o Binding ID mobility option [ID-MCoA]. This option is mandatory if
the sending mobility entity request to terminate one binding of a the sending mobility entity request to terminate one binding of a
multi care-of addresses bindings for the same mobile node. The multi care-of addresses bindings for the same mobile node. The
sending mobility entity may include more than one of the Binding sending mobility entity may include more than one of the Binding
ID mobility options. ID mobility options.
o IPv4 Home Address option which contains the mobile node home IPv4 o IPv4 Home Address option which contains the mobile node home IPv4
address [ID-DSMIP6]. This option is included only when the IPv4 address [ID-DSMIP6]. This option is included only when the IPv4
skipping to change at page 15, line 39 skipping to change at page 15, line 26
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding Revocation Acknowledgement Message Figure 6: Binding Revocation Acknowledgement Message
Status Status
8-bit unsigned integer indicating the result of processing the 8-bit unsigned integer indicating the result of processing the
Binding Revocation Indication message by the receiving mobility Binding Revocation Indication message by the receiving mobility
entity. The following status values are currently defined. entity. Values of the Status field less than 128 indicate that
the Binding Revocation Indication was processed successfully by
the receiving node. Values greater than or equal to 128 indicate
that the Binding Revocation Indication was rejected by the
receiving node. The following status values are currently
defined:
0 success 0 success
1 partial success 1 partial success
128 Binding Does NOT Exist 128 Binding Does NOT Exist
129 IPv4 HoA Binding Does NOT Exist 129 IPv4 HoA Binding Does NOT Exist
130 IPv4 HoA Option Required 130 IPv4 Home Address Option Required
131 Global Revocation NOT Authorized 131 Global Revocation NOT Authorized
132 CAN NOT Identify Binding 132 CAN NOT Identify Binding
133 Revocation Failed, MN is Attached 133 Revocation Failed - MN is Attached
134 Revocation Trigger NOT Supported
135 Revocation Function NOT Supported
Sequence # Sequence #
The sequence number in the Binding Revocation Acknowledgement is The sequence number in the Binding Revocation Acknowledgement is
copied from the Sequence Number field in the Binding Revocation copied from the Sequence Number field in the Binding Revocation
Indication. It is used by the revoking mobility entity, e.g. HA, Indication. It is used by the revoking mobility entity, e.g. HA,
LMA, in matching this Binding Revocation Acknowledgement with the LMA, MAG, in matching this Binding Revocation Acknowledgement with
outstanding BRI. the outstanding BRI.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set if the (P) bit is set in the The Proxy Binding (P) bit is set if the (P) bit is set in the
corresponding Binding Revocation Indication message. corresponding Binding Revocation Indication message.
IPv4 HoA Binding Only (V) IPv4 HoA Binding Only (V)
The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in
the corresponding BRI message. the corresponding BRI message.
skipping to change at page 16, line 47 skipping to change at page 16, line 41
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. In the case contains zero or more TLV-encoded mobility options. In the case
when the Status field is set to success, no mobility option is when the Status field is set to success, no mobility option is
required. The mobility option(s) is usually used to communicate required. The mobility option(s) is usually used to communicate
information of the bindings that failed the revocation procedure. information of the bindings that failed the revocation procedure.
The following options are valid in a Binding Revocation The following mobility options are valid in a Binding Revocation
Acknowledgement: Acknowledgement:
o Home Network Prefix option [RFC5213]. This option MAY be included o Home Network Prefix option [RFC5213]. This option MAY be included
when the (P) bit is set. when the (P) bit is set.
o Mobile Node Identifier Option [RFC4283]. This option MAY be o Mobile Node Identifier Option [RFC4283]. This option MAY be
included when the (P) bit is set. This option SHOULD be included included when the (P) bit is set. This option SHOULD be included
if the Home Network Prefix option is included. if the Home Network Prefix option is included.
o Binding ID mobility option [ID-MCoA]. This option MAY be included o Binding ID mobility option [ID-MCoA]. This option MAY be included
skipping to change at page 17, line 28 skipping to change at page 17, line 21
will be set to 1. will be set to 1.
7. Binding Revocation Process Considerations 7. Binding Revocation Process Considerations
The following subsections describe the details of the binding The following subsections describe the details of the binding
revocation generic process by the different mobility entities. revocation generic process by the different mobility entities.
7.1. Sending Binding Revocation Messages 7.1. Sending Binding Revocation Messages
When sending a Binding Revocation message, the sending mobility node, When sending a Binding Revocation message, the sending mobility node,
initiator, follows the rules of constructing a Mobility Header as in initiator, constructs the packet as it would any other Mobility
Section 9.2 of [RFC3775] with the exception of setting the MH Type Header with the exception of setting the MH Type field to <IANA-TBD>.
field to <IANA-TBD and the appropriate value of the Binding
Revocation Type field.
The mobility entity which initiates the revocation process, The mobility entity which initiates the revocation process MUST use
initiator, MUST use the underlying IPsec security association that the underlying security association, e.g., IPsec SA, that has been
has been used during the mobile node binding registration to secure used to secure the mobile node binding registration signaling in
the BRI and BRA messages transmission with the responding mobility securing the BRI and BRA messages transmission with the responding
entity, responder. mobility entity.
When a mobility entity initiate the binding revocation process by When a mobility entity initiate the binding revocation process by
sending a Binding Revocation Indication message, the initiator MUST sending a Binding Revocation Indication message, the initiator MUST
construct the BRI message as described in Section 6.1. In the BRI 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 message, the initiator MUST set the Sequence Number field to the next
sequence number available for Binding Revocation. Since sending BRI sequence number available for Binding Revocation. Since sending BRI
messages is not done on a regular basis, a 16 bit sequence number 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 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 outstanding BRI with (A) bit set using the sequence number field
only. only.
On the other hand, when the responder acknowledge the BRI message by However, when the responder acknowledges the BRI message by sending a
sending a BRA, the responder MUST construct the Binding Revocation BRA, the responder MUST construct the Binding Revocation
Acknowledgement as described in Section 6.2. In this case, the Acknowledgement as described in Section 6.2. In this case, the
responder MUST set the Sequence Number field by copying the value responder MUST set the Sequence Number field by copying the value
from the Sequence Number field of the received Binding Revocation from the Sequence Number field of the received Binding Revocation
Indication. Additionally, it MUST set the status field to a valid Indication. Additionally, it MUST set the status field to a valid
value that reflects the processing of the received Binding Revocation value that reflects the processing of the received Binding Revocation
Indication. Indication.
7.2. Receiving Binding Revocation Messages 7.2. Receiving Binding Revocation Messages
When receiving a Binding Revocation message, the receiving mobility When receiving a Binding Revocation message, the receiving mobility
node MUST verify the Mobility Header as in [RFC3775]. If the packet node MUST verify the Mobility Header as described in section 9.2. of
is dropped due to failing any of the Mobility Headers test check, the [RFC3775]. If the packet is dropped due to failing any of the
receiving node MUST follow the processing rules as in Section 9.2 of Mobility Headers test check, the receiving node MUST follow the
[RFC3775]. For example, it MUST send a Binding Error message with processing rules as in Section 9.2 of [RFC3775]. If the receiving
the Status field set to 2 (unrecognized MH Type value) if it does not node does not support the Binding Revocation Indication message and
support the received binding revocation message type. does not recognize the new MH type, it sends a Binding Error message
with the Status field set to 2 as described in [RFC3775].
Since some mobility entities, e.g. LMA and MAG, are allowed to 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 receive and possibly send a BRI or BRA for different cases,
mechanism will prevent any possible man in the middle reflection therefore, if IPsec is used to secure signaling between the MAG and
the LMA, it prevents any possible man in the middle reflection
attack. attack.
Upon receiving a packet carrying a Binding Revocation Indication, the Upon receiving a packet carrying a Binding Revocation Indication, the
receiving mobility entity, responder, validates that the packet was receiving mobility entity, responder, validates that the packet was
received protected with the underlying IPsec protection with the received protected with the security association that already has
responding mobility entity. been established with the mobility entity, initiator, and used during
the registration signaling phase, e.g., IPsec SA.
Upon receiving a packet carrying a Binding Revocation Upon receiving a packet carrying a Binding Revocation
Acknowledgement, the receiving mobility entity, initiator, MUST Acknowledgement, the receiving mobility entity, initiator, MUST
validate that Sequence Number field matches the Sequence Number of an validate that Sequence Number field matches the Sequence Number of an
outstanding Binding Revocation Indication that was sent by the outstanding Binding Revocation Indication that was sent by the
initiator. If the Sequence Number does not match any sequence number initiator. If the Sequence Number does not match any sequence number
of any of the outstanding BRI, the receiving node MUST ignore the of any of the outstanding BRI, the receiving node MUST silently
message but MAY log the event. discard the message but MAY log the event.
If a mobility node receives a Binding Revocation Indication message
with the Revocation Trigger field is set to a value that NOT
supported, the receiving mobility node SHOULD reject the BRI message
by sending a BRA message with the status field set to "Revocation
Trigger NOT Supported".
If a mobility node receives a Binding Revocation Indication message
with a Revocation Trigger value that is NOT in line with the BRI
message intent, e.g., the Global Revocation (G) bit set and the
Revocation Trigger field vale is a per-MN specific, the receiving
mobility node SHOULD reject the BRI message by sending a BRA message
with the status field set to "Revocation Function NOT Supported".
7.3. Retransmission of Binding Revocation Indication 7.3. Retransmission of Binding Revocation Indication
If the sending mobility entity does not receive a Binding Revocation If the sending mobility entity does not receive a Binding Revocation
Acknowledgement in response to the outstanding Binding Revocation Acknowledgement in response to the outstanding Binding Revocation
Indication before the MINDelayBRIs timer expires, the mobility Indication before the MINDelayBRIs timer expires, the mobility
entity, e.g. LMA, may retransmit the same BRI message up to the entity, e.g. LMA, may retransmit the same BRI message up to the
BRIMaxRetriesNumber as defined in Section 12. If the revoking BRIMaxRetriesNumber as defined in Section 12. If the revoking
mobility entity does not receive a BRA message after the maximum mobility entity does not receive a BRA message after the maximum
number of retransmits have been sent, the revoking mobility entity number of retransmits have been sent, the revoking mobility entity
can clean the mobile node binding cache and all resources associated can clean the mobile node binding cache and all resources associated
with this binding. The revoking mobility entity may log the event. with this binding. The revoking mobility entity may log the event.
8. Home Agent Operation 8. Home Agent Operation
8.1. Sending Binding Revocation Indication 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 To terminate a mobile node registration and its current binding with
the home agent, the home agent sends a packet to the mobile node the home agent, the home agent sends a packet to the mobile node
containing a Binding Revocation Indication, with the packet containing a Binding Revocation Indication, with the packet
constructed as follows: constructed as follows:
o The Acknowledge (A) bit MAY be set in the BRI to request the o The Acknowledge (A) bit MAY be set in the BRI to request the
mobile node to send a Binding Revocation Acknowledgement upon mobile node to send a Binding Revocation Acknowledgement upon
receipt of the BRI. receipt of the BRI.
o The Revocation Trigger field MUST be set in the Binding Revocation o The Revocation Trigger field MUST be set in the Binding Revocation
Indication to indicate to the mobile node the reason for revoking Indication to indicate to the mobile node the reason for revoking
its IP mobility binding with the home agent. The Revocation its IP mobility binding with the home agent. The Revocation
Trigger may be used by the mobile node to take further steps if Trigger may be used by the mobile node to take further steps if
necessary. necessary.
o The Binding Revocation Indication MUST be sent using a type 2 o The Binding Revocation Indication MUST be sent using a Type 2
routing header which contains the mobile node's registered IPv6 routing header which contains the mobile node's registered IPv6
home address for the binding being revoked. home address for the binding being revoked.
o The care-of address for the binding MUST be used as the o The care-of address for the binding MUST be used as the
destination address in the packet's IPv6 header, unless an destination address in the packet's IPv6 header, unless an
Alternate Care-of Address mobility option is included in the Alternate Care-of Address mobility option is included in the
Binding Revocation Indication. Binding Revocation Indication.
o If the home agent needs to only revoke the mobile node's IPv4 home 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 address binding, the home agent MUST set the IPv4 HoA Binding Only
skipping to change at page 20, line 19 skipping to change at page 20, line 20
When the home agent sends a BRI to the mobile node with the (A) bit 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 set, the home agent sets a flag in the mobile node BCE to indicate
that revocation is in progress and starts the MINDelayBRIs timer. that revocation is in progress and starts the MINDelayBRIs timer.
The home agent maintains the mobile node BCE in this state until it The home agent maintains the mobile node BCE in this state until it
receives a Binding Revocation Acknowledgement or the receives a Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached. BRIMaxRetransmitNumber is reached.
In a race condition case, the home agent may receive a BU from the 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 mobile node while the mobile node's BCE has the revocation in
progress flag set, the home agent should handle this case based on progress flag set, the home agent SHOULD handle this case based on
the reason for sending the Binding Revocation Indication message and the reason for sending the Binding Revocation Indication message and
its local policy. In this case, if the home agent accepts the BU, it 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 needs to update the mobile node BCE accordingly, e.g. removing the
revocation in progress flag. revocation in progress flag.
When the home agent needs to revoke one or more of a mobile node When the home agent needs to revoke one or more of a mobile node
bindings that were created using Multi Care-of address registration bindings that were created using Multi Care-of address registration
as in [ID-MCoA], the home agent MUST include all the related Binding as in [ID-MCoA], the home agent MUST include all the related Binding
ID options that identify these bindings in the Binding Revocation ID options that identify these bindings in the Binding Revocation
Indication message. In the case when the home agent needs to revoke 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 all of the mobile node bindings, the home agent MUST NOT include any
of the Binding ID options. 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 8.2. Receiving Binding Revocation Acknowledgement
When the home agent receives a packet carrying a valid BRA that was When the home agent receives a packet carrying a valid BRA that was
successfully processed as in Section 7.2, the home agent SHOULD successfully processed as in Section 7.2, the home agent SHOULD
examine the Status field as follows: examine the Status field as follows:
o If the Status field indicates that the Binding Revocation o If the Status field indicates that the Binding Revocation
Indication was processed successfully, the home agent deletes the Indication was processed successfully, the home agent deletes the
MINDelayBRIs timer and the mobile node bindings and all related MINDelayBRIs timer and the mobile node bindings and all related
resources. resources.
skipping to change at page 21, line 11 skipping to change at page 21, line 11
home agent SHOULD examine any mobility options included in the home agent SHOULD examine any mobility options included in the
Binding Revocation Acknowledgement. The home agent MAY log the Binding Revocation Acknowledgement. The home agent MAY log the
appropriate event to reflect the status of the received BRA. appropriate event to reflect the status of the received BRA.
9. Local Mobility Anchor Operation 9. Local Mobility Anchor Operation
9.1. Binding Revocation Initiator 9.1. Binding Revocation Initiator
9.1.1. Sending Binding Revocation Indication 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 To terminate a mobile node proxy mobile IPv6 registration and its
current PMIPv6 binding with the local mobility agent, the LMA sends a current PMIPv6 binding with the local mobility agent, the LMA sends a
packet to the MAG containing a BRI message following the procedure in packet to the MAG containing a BRI message following the procedure in
Section 7.1 and the following rules: Section 7.1 and the following rules:
o The Acknowledge (A) bit MAY be set in the Binding Revocation o The Acknowledge (A) bit MAY be set in the Binding Revocation
Indication to request the mobile access gateway to send a Binding Indication to request the mobile access gateway to send a Binding
Revocation Acknowledgement upon receipt of the BRI. Revocation Acknowledgement upon receipt of the BRI.
o The Proxy Mobile IP (P) bit MUST be set in the BRI message to o The Proxy Mobile IP (P) bit MUST be set in the BRI message to
skipping to change at page 23, line 13 skipping to change at page 23, line 5
When the local mobility anchor needs to revoke all mobile nodes proxy When the local mobility anchor needs to revoke all mobile nodes proxy
BCE that are registered with the local mobility anchor and hosted at 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 mobile access gateway, the LMA MUST set the Global (G) bit and
the value of the Revocation Trigger field to "Per-Peer Policy". In 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. 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 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 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 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 Global (G) bit and the value of the Revocation Trigger field to
"Revoking Node Local Policy". In this case, the local mobility "Revoking Mobility Node Local Policy". In this case, the local
anchor MUST include a mobility option to identify the impacted mobility anchor MUST include a mobility option to identify the
bindings, e.g. MN-ID option with a wildcard NAI, e.g. 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 *@companyabc.com, to identify all the mobile nodes BCEs that need to
be removed. be removed.
When the mobile node is registered with multiple Home Network When the mobile node is registered with multiple Home Network
Prefixes for the same proxy care-of address, the local mobility Prefixes for the same proxy care-of address, the local mobility
anchor SHOULD include a HNP option for each registered HNP in the anchor SHOULD include a HNP option for each registered HNP in the
BRI. Alternatively, the LMA MAY include only the mobile node BRI. Alternatively, the LMA MAY include only the mobile node
identifier, MN-ID, option in the BRI to indicate to the mobile access 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 gateway to remove all bindings of the specified mobile node NAI in
the MN-ID option. the MN-ID option.
skipping to change at page 23, line 37 skipping to change at page 23, line 29
When the mobile node is registered with an IPv4 proxy home address in 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 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 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 revoke the mobile node IPv4 proxy HoA binding to the current mobile
node proxy CoA while maintaining the mobile node binding of the HNP 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 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 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 LMA MUST send a BRI message following the procedure in Section 7.1
and the following rules: 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 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. indicate that only the IPv4 home address binding is being revoked.
o The Acknowledge (A) bit MUST be set in the BRI to request the MAG
to send a BRA message.
o The IPv4 Home Address option MUST be included with the mobile o The IPv4 Home Address option MUST be included with the mobile
node's registered IPv4 home address that is being released in node's registered IPv4 home address that is being released in
addition to the MN-ID option. addition to the MN-ID option.
o The mobile node Home Network Prefix option MUST NOT be included. o The mobile node Home Network Prefix option MUST NOT be included.
o The Revocation Trigger field MUST be set to an appropriate value, o The Revocation Trigger field MUST be set to an appropriate value,
e.g. "IPv4 Address Lease Expired". e.g. "IPv4 Address Lease Expired".
9.1.2. Receiving Binding Revocation Acknowledgement 9.1.2. Receiving Binding Revocation Acknowledgement
skipping to change at page 24, line 42 skipping to change at page 24, line 34
When the local mobility anchor receives a packet carrying a Binding When the local mobility anchor receives a packet carrying a Binding
Revocation Indication that was successfully processed as in Revocation Indication that was successfully processed as in
Section 7.2, the local mobility anchor SHOULD in addition process the Section 7.2, the local mobility anchor SHOULD in addition process the
message as follows: message as follows:
o Binding Revocation Indication is formatted as in Section 6.1 and o Binding Revocation Indication is formatted as in Section 6.1 and
if the (P) bit is set, the local mobility anchor MUST validate if the (P) bit is set, the local mobility anchor MUST validate
that all impacted binding(s) have the proxy binding flag set. 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 o If the Global (G) bit is set and the Revocation Trigger value is
the BRI SHOULD contain the mobile access gateway ID in the MN-ID "Per-Peer Policy", the Proxy (P) bit MUST be set and the BRI
option. The local mobility anchor MUST verify that the identified SHOULD contain the mobile access gateway ID in the MN-ID option.
mobile access gateway as per the value in the MN-ID option is The local mobility anchor MUST verify that the identified mobile
authorized to use the Per-Peer Global bindings revocation. The access gateway as per the value in the MN-ID option is authorized
mechanism the LMA uses to verify the MAG authorization is out of to use the Global revocation. The mechanism the LMA uses to
scope of this document. verify the MAG authorization is out of scope of this document.
o If the Global (G) bit is set and only the mobile node identifier, o If the Global (G) bit is set and the Revocation Trigger value is
MN-ID, option is included, the local mobility anchor MUST revoke "Per-Peer Policy", and only the mobile node identifier, MN-ID,
all mobile nodes bindings which proxy CoA is the one used as the 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 source of the IPv6 packet that carried the BRI. However, if one
or more Alternate Care-of Address options are included in addition or more Alternate Care-of Address options are included in addition
to the mobile node identifier option in the BRI message, the local to the mobile node identifier option in the BRI message, the local
mobility anchor MUST revoke all mobile nodes bindings which proxy mobility anchor MUST revoke all mobile nodes bindings which proxy
Care-of Address is one of the Care-of. Care-of Address matches one of the Care-of address(es) in the
Alternate Care-of Address option(s).
o If the Global (G) bit is set and the Revocation Trigger value is
"Per-Peer Policy", and the mobile node identifier, MN-ID, option
is NOT included, the local mobility anchor MUST reject the BRI
message by sending a BRA message with the status field is set to
"Global Revocation Authorization Required".
o The LMA identifies all impacted mobile nodes bindings and if the o The LMA identifies all impacted mobile nodes bindings and if the
Acknowledgement (A) bit is set, the local mobility anchor MUST Acknowledgement (A) bit is set, the local mobility anchor MUST
send a Binding Revocation Acknowledgement following Section 9.2.2 send a Binding Revocation Acknowledgement following Section 9.2.2
using the appropriate status code. using the appropriate status code.
o If the Global (G) bit is NOT set, the local mobility anchor MUST o If the Global (G) bit is NOT set, the local mobility anchor SHOULD
use the included mobility options to identify the impacted mobile use the included mobility options to identify the impacted mobile
node binding as follows: node binding as follows:
1. If only the mobile node identifier, MN-ID, option is included, 1. If only the mobile node identifier, MN-ID, option is included,
the local mobility anchor MUST revoke all bindings for this the local mobility anchor MUST revoke all bindings for this
mobile node which use the specified mobile node NAI. mobile node which use the specified mobile node NAI.
2. If the mobile node identifier, MN-ID, and the Home Network 2. If the mobile node identifier, MN-ID, and the Home Network
Prefix option are included, the local mobility anchor MUST Prefix option are included, the local mobility anchor MUST
only remove the specified proxy binding. only remove the specified proxy binding.
skipping to change at page 27, line 13 skipping to change at page 27, line 6
status value. status value.
o If the Global (G) bit is set and the Revocation Trigger field is 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 set to "Per-Peer policy", the mobile access gateway identifies all
bindings that are registered at the LMA and hosted at the MAG. bindings that are registered at the LMA and hosted at the MAG.
This Binding Revocation Indication does not include any other This Binding Revocation Indication does not include any other
mobility options. In this case, the MAG MUST send a BRA with the mobility options. In this case, the MAG MUST send a BRA with the
appropriate status code to the LMA. appropriate status code to the LMA.
o If the Global (G) bit is set and the Revocation Trigger field is 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 set to "Revoking Mobility Node Local Policy", the MAG MUST
bindings that are registered at the LMA and hosted at the MAG identify all bindings that are registered at the LMA and hosted at
using the mobility option(s) included in the BRI. This Binding the MAG using the mobility option(s) included in the BRI. This
Revocation Indication SHOULD include at least the MN-ID option, Binding Revocation Indication SHOULD include at least the MN-ID
e.g. with a wild card NAI. In this case, the MAG MUST send a BRA option, e.g. with a wild card NAI. In this case, the MAG MUST
with the appropriate status code to the LMA. 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 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 set to "Revoking Mobility Node Local Policy", and no mobility
included in the Binding Revocation Indication message or the MAG options are included in the Binding Revocation Indication message
is not able to identify the impacted mobile nodes bindings based or the MAG is not able to identify the impacted mobile nodes
on the included mobility options, the MAG MUST treat this as an bindings based on the included mobility options, the MAG MUST
error scenario. In this case, the MAG SHOULD send a Binding treat this as an error scenario. In this case, the MAG SHOULD
Revocation Acknowledgement message with status "CAN NOT Identify send a Binding Revocation Acknowledgement message with status "CAN
Binding". NOT Identify Binding".
o If the Revocation Trigger field value in the received Binding o If the Revocation Trigger field value in the received Binding
Revocation Indication message indicates an inter-MAG handover and Revocation Indication message indicates an inter-MAG handover and
the (A) bit is set, the MAG use the mobility option(s) included in 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 the BRI message to identify the mobile node binding. The mobile
access gateway MAY validate that the mobile node is no longer access gateway MAY validate that the mobile node is no longer
attached to the mobile access gateway before sending a successful attached to the mobile access gateway before sending a successful
Binding Revocation Acknowledgement message to the LMA. However, Binding Revocation Acknowledgement message to the LMA. However,
if the Revocation Trigger field is set to "Inter-MAG - Unknown if the Revocation Trigger field is set to "Inter-MAG - Unknown
Handoff" and the (A) bit is set, the MAG MUST validate that the Handoff" or "Possible Out-of Sync BCE State" and the (A) bit is
mobile node is no longer attached to the MAG before sending a set, the MAG MUST validate that the mobile node is no longer
successful BRA message and deleting the resources associated with attached to the MAG before sending a successful BRA message and
the mobile node binding. Otherwise, if the MAG verified that the deleting the resources associated with the mobile node binding.
MN is still attached, the MAG MUST set the status field in the BRA Otherwise, if the MAG verified that the MN is still attached, the
to "Revocation failed - MN is attached". 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 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 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 binding entry in the BUL. The MAG MUST verify that the IPv4
address included in the IPv4 Home Address option in the received 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 BRI is the same as the IPv4 proxy HoA that is assigned to the
mobile node. After the MAG successfully validates the received mobile node. After the MAG successfully validates the received
IPv4 home address as the mobile node IPv4 HoA, the MAG MUST IPv4 home address as the mobile node IPv4 HoA, the MAG MUST
consider this as an indication to release the mobile node IPv4 consider this as an indication to release the mobile node IPv4
proxy HoA binding to the mobile node current proxy CoA ONLY. proxy HoA binding to the mobile node current proxy CoA ONLY.
skipping to change at page 28, line 19 skipping to change at page 28, line 12
MN pCoA. In this case, the MAG MUST send a BRA message with 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 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 able to identify the mobile node binding using the MN-ID but
failed to identify the received IPv4 proxy HoA, the MAG MUST send 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 a BRA with status field is set to "IPv4 HoA Binding Does NOT
Exist". Exist".
The Revocation Trigger field value in the received BRI could be used 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 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 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 has been terminated, e.g., if the Revocation Trigger field is set to
"Administrative Reason", the mobile access gateway may send a RA "Administrative Reason", the mobile access gateway may send a RA
message after setting the Home Network Prefix lifetime to zero. message after setting the Home Network Prefix lifetime to zero.
10.1.2. Sending Binding Revocation Acknowledgement 10.1.2. Sending Binding Revocation Acknowledgement
When the mobile access gateway receive a valid Binding Revocation When the mobile access gateway receive a valid Binding Revocation
Indication with the (A) bit set and after processing the BRI message, Indication with the (A) bit set and after processing the BRI message,
the mobile access gateway sends a packet to the local mobility anchor the mobile access gateway sends a packet to the local mobility anchor
containing a Binding Revocation Acknowledgement according to the containing a Binding Revocation Acknowledgement according to the
procedure in Section 7.1 and the following: procedure in Section 7.1 and the following:
skipping to change at page 29, line 15 skipping to change at page 29, line 11
o The destination IP address of the IPv6 packet of the Binding o The destination IP address of the IPv6 packet of the Binding
Revocation Acknowledgement is set to the source IP address of the Revocation Acknowledgement is set to the source IP address of the
received Binding Revocation Indication. received Binding Revocation Indication.
10.2. Binding Revocation Initiator 10.2. Binding Revocation Initiator
10.2.1. Sending Binding Revocation Indication 10.2.1. Sending Binding Revocation Indication
The mobile access gateway could send a Binding Revocation Indication The mobile access gateway could send a Binding Revocation Indication
message to indicate the termination of multiple mobile node bindings, message to indicate the termination of multiple mobile node bindings,
e.g., when using the global revocation with the Global (G) bit is e.g., when using the global revocation with the Global (G) bit set.
set. In this case when an event occurs which requires the mobile In this case when an event occurs which requires the mobile access
access gateway to inform the LMA to terminate all mobile nodes gateway to inform the LMA to terminate all mobile nodes bindings that
bindings that are registered at the local mobility anchor and the are registered at the local mobility anchor and the mobile access
mobile access gateway, the mobile access gateway sends a Binding gateway, the mobile access gateway sends a Binding Revocation
Revocation Indication message following Section 7.1 and the Indication message following Section 7.1 and the following:
following:
o The Acknowledge (A) bit MUST be set in the Binding Revocation o The Acknowledge (A) bit MUST be set in the Binding Revocation
Indication to request the local mobility anchor to send a Binding Indication to request the local mobility anchor to send a Binding
Revocation Acknowledgement upon receipt of the BRI. Revocation Acknowledgement upon receipt of the BRI.
o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation 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 Indication to indicate that bindings that being revoked is a proxy
Mobile IPv6 binding. Mobile IPv6 binding.
o The Global (G) bit MUST be set and the Revocation Trigger contains o The Global (G) bit MUST be set and the Revocation Trigger contains
skipping to change at page 31, line 10 skipping to change at page 31, line 6
o If the Acknowledgement (A) bit is set in the Binding Revocation o If the Acknowledgement (A) bit is set in the Binding Revocation
Indication and its Binding Update List contains an entry for the Indication and its Binding Update List contains an entry for the
IP address in the type 2 routing header, the mobile node MUST send IP address in the type 2 routing header, the mobile node MUST send
a Binding Revocation Acknowledgement. However, in all other cases a Binding Revocation Acknowledgement. However, in all other cases
when the (A) bit is set in the BRI, the mobile node SHOULD send a when the (A) bit is set in the BRI, the mobile node SHOULD send a
Binding Revocation Acknowledgement. In all cases, the mobile node Binding Revocation Acknowledgement. In all cases, the mobile node
MUST follow Section 11.2 and send a BRA using the appropriate MUST follow Section 11.2 and send a BRA using the appropriate
status code. status code.
o If the IPv4 HoA Binding Only (V) bit is set in the received BRI 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 message, the MN MUST verify that there is an IPv4 Home Address
the received BRI and the IPv4 address included in the IPv4 Home option in the received BRI and the IPv4 address included in the
Address option is the same as its IPv4 HoA that is assigned to the IPv4 Home Address option is the same as its IPv4 HoA that is
mobile node. If this verification is successful, the MN MUST assigned to the mobile node. If this verification is successful,
consider this BRI as an indication to release the mobile node IPv4 the MN MUST consider this BRI as an indication to release the
HoA binding to its current Care-of Address ONLY. Consequently, mobile node IPv4 HoA binding ONLY to its current Care-of Address.
the MN MUST continue to maintain its IPv6 HoA binding to the Consequently, the MN MUST continue to maintain its IPv6 HoA
current CoA as part of the mobile node binding in the BUL entry binding to the current CoA as part of the mobile node binding in
and release all resources associated with the MN IPv4 HoA binding. the BUL entry and release all resources associated with the MN
In this case, the MN MUST send a BRA message with the status field IPv4 HoA binding. In this case, the MN MUST send a BRA message
is set to success. On the other hand, if the IPv4 HoA option was with the status field is set to success. On the other hand, if
NOT included in the received BRI with the (V) bit set, the MN the IPv4 Home Address Option was NOT included in the received BRI
SHOULD send a BRA message with the status field set to "IPv4 HoA with the (V) bit set, the MN SHOULD send a BRA message with the
Option Required". Additionally, if the verification received IPv4 status field set to "IPv4 Home Address Option Required".
HoA in the IPv4 HoA option is NOT the one assigned to the MN, the Additionally, if the IPv4 HoA received in the IPv4 Home Address
MN SHOULD send a BRA with the status field is set to "IPv4 HoA Option is NOT the one assigned to the MN, the MN SHOULD send a BRA
Binding Does NOT Exist". with the status field set to "IPv4 HoA Binding Does NOT Exist".
o The mobile node MUST verify that the (P) bit in the Binding 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 Revocation Indication is NOT set. If the (P) bit is set, the
mobile node MUST silently discard the Binding Revocation mobile node MUST silently discard the Binding Revocation
Indication message. Indication message.
o If the mobile node has registered multiple care-of addresses with o If the mobile node has registered multiple care-of addresses with
its home agent, the mobile node MUST verify which binding is being its home agent, the mobile node MUST verify which binding is being
revoked by examining the content of the BRI message. If the revoked by examining the content of the BRI message. If the
mobile node received a Binding Revocation Indication with a single mobile node received a Binding Revocation Indication with a single
skipping to change at page 32, line 48 skipping to change at page 32, line 46
The default value for this parameter is 1. The default value for this parameter is 1.
Minimum Delay Between BRI messages (MINDelayBRIs) Minimum Delay Between BRI messages (MINDelayBRIs)
This variable specifies the delay time in seconds before the This variable specifies the delay time in seconds before the
revoking mobility entity retransmits a BRI message. The default revoking mobility entity retransmits a BRI message. The default
is 1 second but not less than 0.5 seconds. is 1 second but not less than 0.5 seconds.
13. IANA Considerations 13. IANA Considerations
This document defines two new messages BRI and BRA, as described in This document defines a new Binding Revocation Message using a new
Section 6.1 and Section 6.2 by using Binding Revocation types of 1 Mobility Header Type <IANA-TBD>, as described in Section 6. The new
and 2 of the Binding Revocation Message which is defined in in Mobility Header type value needs to be assigned from the same
Section 6 and uses a MH type <IANA-TBD>. The new Mobility Header numbering space as allocated for the other Mobility Header types.
type value needs to be assigned from the same numbering space as
allocated for the other Mobility Header types. This document also creates a new name space "Binding Revocation Type"
which indicates the type of the binding revocation message. The
current binding revocation message types are described in Section 6.1
and Section 6.2, and are the following:
0 Reserved
1 Binding Revocation Indication
2 Binding Revocation Acknowledgement
All other values are reserved
Future values of the Binding Revocation Type can be allocated using
Standards Action or IESG Approval [RFC2434].
In addition, this document also creates a second new namespace for
the Binding Revocation Trigger which indicates the reason behind
sending the Binding Revocation Indication message. The current
Binding Revocation Trigger values are described in Section 6.1, and
are the following:
Reserved and Per-MN Revocation Trigger Values:
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 User Initiated Session(s) Termination
7 Access Network Session(s) Termination
8 IPv4 HoA Lease Expires
9 Possible Out-of Sync BCE State
250-255 Reserved For Testing Purposes only
All other values are Reserved
Global Revocation Trigger Values:
128 Per-Peer Policy
129 Revoking Mobility Node Local Policy
Future values of the Binding Revocation Trigger can be allocated
using Standards Action or IESG Approval [RFC2434].
Furthermore, this document creates a third new name space "Status
Code" for the Status field in the Binding Revocation Acknowledgement
message. The current values are described in Section 6.2, and are
the following:
0 success
1 partial success
128 Binding Does NOT Exist
129 IPv4 HoA Binding Does NOT Exist
130 IPv4 Home Address Option Required
131 Global Revocation NOT Authorized
132 CAN NOT Identify Binding
133 Revocation Failed - MN is Attached
Future values of the Status field can be allocated using Standards
Action or IESG Approval [RFC2434].
All fields labeled "Reserved" are only to be assigned through
Standards Action or IESG Approval.
14. Security Considerations 14. Security Considerations
The protocol described here uses the same security association 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 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 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 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 MUST allow the MH type for the Binding Revocation Message defined in
this document. this document.
However, in the case when the MAG sends a BRI message with the Global 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 (G) bit is set and the Revocation Trigger field is set to "Per-Peer
Per-Peer Global Revocation. policy", the LMA MUST verify that the MAG is authorized to use Per-
Peer Global Revocation.
15. Acknowledgements 15. Acknowledgements
The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- The authors would like to thank Ryuji Wakikawa, Bruno Mongazon-
Cazavet, Domagoj Premec, Arnaud Ebalard, and Patrick Stupar for their Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay
review and comments of this draft and all colleagues who have Devarapalli, and Joel Hortelius for their review and comments of this
supported the advancement of this draft effort. draft and all colleagues who have supported the advancement of this
draft effort.
16. References 16. References
16.1. Normative References 16.1. Normative References
[ID-DSMIP6] [ID-DSMIP6]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-07 (work in Routers", draft-ietf-mext-nemo-v4traversal-07 (work in
progress), December 2008. progress), December 2008.
skipping to change at page 34, line 6 skipping to change at page 35, line 18
January 2009. January 2009.
[ID-PMIP6-IPv4] [ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
(work in progress), January 2009. (work in progress), January 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
 End of changes. 89 change blocks. 
310 lines changed or deleted 374 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/