draft-ietf-mext-binding-revocation-10.txt   draft-ietf-mext-binding-revocation-11.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: February 16, 2010 S. Gundavelli Expires: March 9, 2010 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
August 15, 2009 September 05, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-10.txt draft-ietf-mext-binding-revocation-11.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. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 February 16, 2010. This Internet-Draft will expire on March 9, 2010.
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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document defines a binding revocation mechanism to terminate a This document defines a binding revocation mechanism to terminate a
mobile node's mobility session and the 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 Mobile IPv6 and its extensions. This mechanism allows the case of Mobile IPv6 and its extensions. This mechanism allows
the mobility entity which initiates the revocation procedure to the mobility entity which initiates the revocation procedure to
request its corresponding one to terminate either one, multiple or request its peer to terminate either one, multiple or all specified
all specified binding cache entries. binding(s).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5
2.1. Conventions used in this document . . . . . . . . . . . . 5 2.1. Conventions used in this document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5
3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 6 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 6
3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 7 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 7
3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 8 3.3. Multiple Care-of Addresses (Monami6) Use Case . . . . . . 8
3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 9 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 9
3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding
Revocation . . . . . . . . . . . . . . . . . . . . . . 10 Revocation . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11
4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Binding Revocation Messages over IPv4 Transport Network . . . 12
5. Binding Revocation Messages over IPv4 Transport Network . . . 12 5. Binding Revocation Message . . . . . . . . . . . . . . . . . . 12
6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 13 5.1. Binding Revocation Indication Message . . . . . . . . . . 14
6.1. Binding Revocation Indication Message . . . . . . . . . . 14 5.2. Binding Revocation Acknowledgement Message . . . . . . . . 17
6.2. Binding Revocation Acknowledgement Message . . . . . . . . 17 6. Binding Revocation Process Operation . . . . . . . . . . . . . 20
7. Binding Revocation Process Operation . . . . . . . . . . . . . 20 6.1. Sending Binding Revocation Messages . . . . . . . . . . . 20
7.1. Sending Binding Revocation Messages . . . . . . . . . . . 20 6.2. Receiving Binding Revocation Messages . . . . . . . . . . 21
7.2. Receiving Binding Revocation Messages . . . . . . . . . . 21 6.3. Retransmission of Binding Revocation Indication . . . . . 22
7.3. Retransmission of Binding Revocation Indication . . . . . 22 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 7.1. Sending Binding Revocation Indication . . . . . . . . . . 22
8.1. Sending Binding Revocation Indication . . . . . . . . . . 22 7.2. Receiving Binding Revocation Acknowledgement . . . . . . . 24
8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 24 8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24
9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24 8.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24
9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24 8.1.1. Sending Binding Revocation Indication . . . . . . . . 24
9.1.1. Sending Binding Revocation Indication . . . . . . . . 24 8.1.2. Receiving Binding Revocation Acknowledgement . . . . . 29
9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 28 8.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29
9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29 8.2.1. Receiving Binding Revocation Indication . . . . . . . 29
9.2.1. Receiving Binding Revocation Indication . . . . . . . 29 8.2.2. Sending Binding Revocation Acknowledgement . . . . . . 31
9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 30 9. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 32
10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 31 9.1. Binding Revocation Responder . . . . . . . . . . . . . . . 32
10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 31 9.1.1. Receiving Binding Revocation Indication . . . . . . . 32
10.1.1. Receiving Binding Revocation Indication . . . . . . . 31 9.1.2. Sending Binding Revocation Acknowledgement . . . . . . 34
10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 33 9.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 35
10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 34 9.2.1. Sending Binding Revocation Indication . . . . . . . . 35
10.2.1. Sending Binding Revocation Indication . . . . . . . . 34 9.2.2. Receiving Binding Revocation Acknowledgement . . . . . 36
10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 35 10. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 36
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 35 10.1. Receiving Binding Revocation Indication . . . . . . . . . 36
11.1. Receiving Binding Revocation Indication . . . . . . . . . 35 10.2. Sending Binding Revocation Acknowledgement . . . . . . . . 38
11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 37 11. Protocol Configuration Variables . . . . . . . . . . . . . . . 38
12. Protocol Configuration Variables . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 13. Security Considerations . . . . . . . . . . . . . . . . . . . 40
14. Security Considerations . . . . . . . . . . . . . . . . . . . 39 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 15.1. Normative References . . . . . . . . . . . . . . . . . . . 41
16.1. Normative References . . . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . . 42
16.2. Informative References . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
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. A similar Mobile IPv4 mobility service using its Home Address. A similar Mobile IPv4
registration revocation mechanism [RFC3543] has been specified by registration revocation mechanism [RFC3543] has been specified by
IETF for providing a revocation mechanism for sessions that were IETF for providing a revocation mechanism for sessions that were
established using Mobile IPv4 registration [RFC3344]. established using Mobile IPv4 registration [RFC3344].
This document specifies a binding revocation mechanism that can be This document specifies a binding revocation mechanism that can be
used to revoke a mobile node's mobility session(s). The same used to revoke a mobile node's mobility session(s). The same
mechanism can be used to revoke bindings created using Mobile IPv6 mechanism can be used to revoke bindings created using Mobile IPv6
[RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6 [RFC3775] or any of its extensions, e.g. Proxy Mobile IPv6
[RFC5213]. The proposed revocation mechanism uses a new MH type [RFC5213]. The proposed revocation mechanism uses a new Mobility
<IANA-TBD> for revocation signaling which is applicable to Mobile Header (MH) type <IANA-TBD> for revocation signaling which is
IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used by any applicable to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213]
two IP mobility entities. As an example, this mechanism allows a and can be used by any two IP mobility entities. As an example, this
local mobility anchor (LMA), involved in providing IP mobility mechanism allows a local mobility anchor (LMA), involved in providing
services to a mobile node, to notify the mobile access gateway (MAG) IP mobility services to a mobile node, to notify the mobile access
of the termination of a mobile node binding registration. In another gateway (MAG) of the termination of that mobile node binding
example, a mobile access gateway can use this mechanism to notify its registration. In another example, a mobile access gateway can use
local mobility anchor peer with a bulk termination of all or a subset this mechanism to notify its local mobility anchor peer with a bulk
of proxy mobile IPv6 (PMIPv6) bindings that are registered with the termination of all or a subset of proxy mobile IPv6 (PMIPv6) bindings
local mobility anchor and currently being served by the mobile access that are registered with the local mobility anchor and currently
gateway. being served by the mobile access gateway. Any mobility entity is
allowed to revoke only the registration of those mobile node(s)
mobility sessions that are currently registered with it.
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
skipping to change at page 6, line 7 skipping to change at page 6, line 9
IPv6 [RFC5213] specifications. IPv6 [RFC5213] specifications.
3. Binding Revocation Protocol and Use Cases Overview 3. Binding Revocation Protocol and Use Cases Overview
This specification specifies a generic binding revocation mechanism This specification specifies a generic binding revocation mechanism
where a mobility node can communicate to the mobile node or another where a mobility node can communicate to the mobile node or another
mobility node the identity of the the mobile node registration mobility node the identity of the the mobile node registration
binding that is being terminated. In the case when this mechanism is binding that is being terminated. In the case when this mechanism is
used for bulk termination or multiple bindings, the identities of used for bulk termination or multiple bindings, the identities of
these bindings are communicated to the mobile node or mobility node these bindings are communicated to the mobile node or mobility node
using the same generic mechanism. The following subsections describe using the same generic mechanism. The following subsections present
the protocol overview and applicable use cases. the protocol overview and applicable use cases.
3.1. Binding Revocation Protocol 3.1. Binding Revocation Protocol
In the case of Mobile IPv6, if the home network decides to terminate In the case of Mobile IPv6, if the home network decides to terminate
the service of the mobile node, the home agent sends a Binding the service of the mobile node, the home agent sends a Binding
Revocation Indication (BRI) message to the mobile node. The home Revocation Indication (BRI) message to the mobile node. The home
agent includes the home address (HoA) of the mobile node in the Type agent includes the home address (HoA) of the mobile node in the Type
2 routing header as specified in [RFC3775] to indicate the impacted 2 routing header as specified in [RFC3775] to indicate the impacted
mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6)
skipping to change at page 7, line 4 skipping to change at page 7, line 6
registration message by sending a Proxy Binding Update with a registration message by sending a Proxy Binding Update with a
lifetime of zero to indicate to the local mobility anchor of the lifetime of zero to indicate to the local mobility anchor of the
termination of the PMIPv6 mobile node binding registration. In this termination of the PMIPv6 mobile node binding registration. In this
case, the mobile access gateway includes the MN-HNP option, the MN-ID case, the mobile access gateway includes the MN-HNP option, the MN-ID
option and all other required mobility options as per [RFC5213] in option and all other required mobility options as per [RFC5213] in
order for the local mobility anchor to identify the mobile node order for the local mobility anchor to identify the mobile node
PMIPv6 binding. Additionally, in the case when the mobile access PMIPv6 binding. Additionally, in the case when the mobile access
gateway communicates a bulk termination of PMIPv6 mobility sessions, gateway communicates a bulk termination of PMIPv6 mobility sessions,
the mobile access gateway sends a Binding Revocation Indication the mobile access gateway sends a Binding Revocation Indication
message with the Global (G) and Acknowledge (A) bits set and includes message with the Global (G) and Acknowledge (A) bits set and includes
the mobile access gateway identity in the MN-ID option. When the the mobile access gateway identity in the MN-ID option, see sections
local mobility anchor receives such Binding Revocation Indication Section 8.1.1 and Section 9.1.1. When the local mobility anchor
message, it ensures that the mobile access gateway is authorized to receives such Binding Revocation Indication message, it ensures that
send such bulk termination message and then processes the Binding the mobile access gateway is authorized to send such bulk termination
Revocation Indication message accordingly. If the local mobility message and then processes the Binding Revocation Indication message
anchor processes the Binding Revocation Indication message accordingly. If the local mobility anchor processes the Binding
successfully, the local mobility anchor responds to the mobile access Revocation Indication message successfully and the Acknowledge (A)
bit was set, the local mobility anchor responds to the mobile access
gateway by sending Binding Revocation Acknowledgement message. gateway by sending Binding Revocation Acknowledgement message.
In any of the above cases, the initiator of the binding revocation In any of the above cases, the initiator of the binding revocation
procedure, e.g., home agent, local mobility anchor, mobile access procedure, e.g., home agent, local mobility anchor, or mobile access
gateway, uses the Revocation Trigger field in the Binding Revocation gateway, uses the Revocation Trigger field in the Binding Revocation
Indication message to indicate to the receiving node the reason for Indication message to indicate to the receiving node the reason for
initiating the revocation procedure. initiating the revocation procedure.
3.2. MIPv6 and DSMIP6 Use Case 3.2. MIPv6 and DSMIP6 Use Case
Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 The binding revocation mechanism is applicable to Mobile IPv6 and
session(s) when the home agent needs to inform the mobile node that DSMIPv6 session(s) when the home agent needs to inform the mobile
its binding registration has been revoked, e.g. for an administrative node that its binding registration has been revoked, e.g. for an
reason. This mechanism enables the user to react to the revocation, administrative reason. This mechanism enables the user or the mobile
e.g., reinstate its interrupted Mobile IPv6 services. node to react to the revocation, e.g., reinstate its interrupted
Mobile IPv6 services.
In this case, the home agent sends a Binding Revocation Indication In this case, the home agent sends a Binding Revocation Indication
message to indicate to the mobile node that its current mobile IPv6 message to indicate to the mobile node that its current mobile IPv6
(MIPv6) binding has been revoked and it no longer able to receive IP (MIPv6) binding has been revoked and it is no longer able to receive
mobility service. The home agent includes the HoA in Type 2 routing IP mobility service. The home agent includes the HoA in Type 2
header as used in [RFC3775] and sets the Revocation Trigger field to routing header as used in [RFC3775] and sets the Revocation Trigger
a proper value, e.g., Administrative Reason. In the case of DSMIPv6 field to a proper value, e.g., Administrative Reason. In the case of
session, the home agent may additionally include the mobile node DSMIPv6 session, the home agent may additionally include the mobile
assigned IPv4 Home Address in the IPv4 Home Address option. When the node assigned IPv4 Home Address in the IPv4 Home Address option.
mobile node receives the Binding Revocation Indication message, it When the mobile node receives the Binding Revocation Indication
sends a Binding Revocation Acknowledgement message as described in message, it sends a Binding Revocation Acknowledgement message as
Section 11.2 to the home agent. Figure 1 illustrates the message described in Section 10.2 to the home agent. Figure 1 illustrates
sequencing when home agent revokes a mobile node binding the message sequencing when home agent revokes a mobile node binding
registration. registration.
MN HA MN HA
| | | |
| HoA in Type 2 Hdr | | HoA in Type 2 Hdr |
|<<<------------... + ...-----------------| |<<<------------... + ...-----------------|
| BRI [seq.#, A bit, Revocation Trigger] | | BRI [seq.#, A bit, Revocation Trigger] |
| | | |
| | | |
| BRA (HoA in Dest. Option)[seq.#, Status] | | 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. Multiple Care-of Addresses (Monami6) Use Case
In the case of multiple care-of addresses registration [ID-MCoA], the In the case of multiple care-of addresses registration [ID-MCoA], the
home agent maintains different binding for each pair of care-of home agent maintains different binding for each pair of care-of
address and home address. These bindings are also indexed and address and home address. These bindings are also indexed and
identified during the mobile node registration using a BID mobility identified during the mobile node registration using a BID mobility
option. The HA may revoke one or multiple bindings for the same option. The HA may revoke one or multiple bindings for the same
mobile node home address. mobile node home address.
If the home agent revokes a single binding for a mobile node with If the home agent revokes a single binding for a mobile node with
multiple care-of addresses registration, the home agent sends a multiple care-of addresses registration, the home agent sends a
skipping to change at page 9, line 33 skipping to change at page 9, line 33
Additionally, the home agent may revoke all of the mobile node Additionally, the home agent may revoke all of the mobile node
registered bindings, by sending a BRI message without including any registered bindings, by sending a BRI message without including any
BID options while the HoA is included in the Type 2 routing header. BID options while the HoA is included in the Type 2 routing header.
Figure 1 illustrates the message flow when the home agent revokes all Figure 1 illustrates the message flow when the home agent revokes all
registered Care-of addresses bindings for a mobile node in a single registered Care-of addresses bindings for a mobile node in a single
Binding Revocation Indication message. Binding Revocation Indication 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 the 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, i.e., mobile access gateway and local mobility the mobility entities, i.e., mobile access gateway and local mobility
anchor, are always synchronized with respect to the status of the anchor, are always synchronized with respect to the status of the
existing PMIPv6 bindings. The binding revocation mechanism is existing PMIPv6 bindings. The binding revocation mechanism is
generic enough that can be used for all Proxy Mobile IPv6 scenarios generic enough that can be used for all Proxy Mobile IPv6 scenarios
that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. that follow [RFC5213] and [ID-PMIP6-IPv4] specifications.
When the mobile access gateway receives a Binding Revocation When the mobile access gateway receives a Binding Revocation
Indication message as in Section 10.1.1, the mobile access gateway Indication message with the Acknowledge (A) bit set as in
sends a Binding Revocation Acknowledgement message to the local Section 9.1.1, the mobile access gateway sends a Binding Revocation
mobility anchor following the rules described in Section 10.1.2. Acknowledgement message to the local mobility anchor following the
Similarly, if the local mobility anchor receives a Binding Revocation rules described in Section 9.1.2. Similarly, if the local mobility
Indication message with the Acknowledge (A) bit is set, the local anchor receives a Binding Revocation Indication message with the
mobility anchor responds to the mobile access gateway by sending a Acknowledge (A) bit is set, the local mobility anchor responds to the
Binding Revocation Acknowledgement message. mobile access gateway by sending a Binding Revocation Acknowledgement
message.
3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation
The local mobility anchor may send a Binding Revocation Indication The local mobility anchor may send a Binding Revocation Indication
message to the mobile access gateway, hosting a specific PMIPv6 message with the appropriate revocation trigger value to the mobile
binding, with the appropriate value in the revocation trigger field access gateway that hosts a specific PMIPv6 binding to indicate that
to indicate that the mobile node binding has been terminated and the the mobile node binding has been terminated and the mobile access
mobile access gateway can clean up the applicable resources. When gateway can clean up the applicable resources. When the mobile
the mobile access gateway receives a Binding Revocation Indication access gateway receives a Binding Revocation Indication message, the
message, the mobile access gateway identifies the respected binding mobile access gateway identifies the respected binding and if the
and if the Acknowledge (A) bit was set in the received Binding Acknowledge (A) bit is set in the received Binding Revocation
Revocation Indication message, it sends a Binding Revocation Indication message, it sends a Binding Revocation Acknowledgement
Acknowledgement message to the local mobility anchor. In this case, message to the local mobility anchor. In this case, the mobile
the mobile access gateway could send a Router Advertisement message access gateway could send a Router Advertisement message to the
to the mobile node with the home network prefix valid lifetime set to mobile node with the home network prefix valid lifetime set to zero.
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 mobile access gateway revoking a mobile node binding at the source mobile access gateway
during the mobile node inter-MAG handover. During the inter-MAG during the mobile node inter-MAG handover. During the inter-MAG
handover, the mobile node moves from the source MAG to the target handover, the mobile node moves from the source MAG to the target
MAG. The target MAG sends a Proxy Binding Update with the new care- MAG. The target MAG sends a Proxy Binding Update with the new care-
of-address to the local mobility anchor to update the mobile node's of-address to the local mobility anchor to update the mobile node's
point of attachment. Since the mobile node binding at the local point of attachment. Since the mobile node binding at the local
mobility anchor points to the source MAG and upon receiving the Proxy mobility anchor points to the source MAG and upon receiving the Proxy
Binding Update from the target MAG, the local mobility anchor updates Binding Update from the target MAG, the local mobility anchor updates
the MN BCE and send a Proxy Binding Acknowledgement to the target the MN Binding Cache Entry (BCE) and send a Proxy Binding
MAG. The local mobility anchor can send a Binding Revocation Acknowledgement to the target MAG. The local mobility anchor can
Indication message with the appropriate revocation trigger value, send a Binding Revocation Indication message with the appropriate
e.g. inter-MAG handover - different Access Types, to the source MAG revocation trigger value, e.g. inter-MAG handover - different Access
in order to clean up the applicable resources reserved for the Types, to the source MAG in order to clean up the applicable
specified mobile node binding. The mobile access gateway resources reserved for the specified mobile node binding. If the
acknowledges the Binding Revocation Indication message by sending a Acknowledge (A) bit is set, the mobile access gateway acknowledges
Binding Revocation Acknowledgement message to indicate the success or the Binding Revocation Indication message by sending a Binding
failure of the termination of the mobile node's binding. Revocation Acknowledgement message to indicate the success or failure
of the termination of the mobile node's binding.
The process identified above can also be used by the local mobility The process identified above can also be used by the local mobility
anchor in scenarios other than the inter-MAG handover with the proper anchor in scenarios other than the inter-MAG handover with the proper
revocation trigger value to indicate to the peer mobile access revocation trigger value to indicate to the peer mobile access
gateway that a specific PMIPv6 binding or bindings have been revoked. gateway that a specific PMIPv6 binding or bindings have been revoked.
oldMAG newMAG LMA oldMAG newMAG LMA
| | | | | |
| | PBU | | | PBU |
| |--------------------------->| | |--------------------------->|
skipping to change at page 11, line 33 skipping to change at page 11, line 33
|----------------------------------------->| |----------------------------------------->|
| | | | | |
| | | | | |
Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover
In addition, the local mobility anchor can send a Binding Revocation In addition, the local mobility anchor can send a Binding Revocation
Indication message to indicate that all bindings which are hosted by Indication message to indicate that all bindings which are hosted by
the peer mobile access gateway and registered with the local mobility the peer mobile access gateway and registered with the local mobility
anchor are being revoked by setting the Global (G) bit as described anchor are being revoked by setting the Global (G) bit as described
in Section 9.1.1. in Section 8.1.1.
3.4.2. 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 Global (G) bit The mobile access gateway sends a BRI message with the Global (G) bit
is set to indicate that all mobility bindings which are registered at set and the Revocation Trigger field is set to "Per-Peer Policy" to
the local mobility anchor and attached to the mobile access gateway indicate that all mobility bindings which are registered at the local
are being revoked as in Section 10.2.1. When the local mobility mobility anchor and attached to the mobile access gateway are being
anchor receives a Binding Revocation Indication message with the revoked as in Section 9.2.1. When the local mobility anchor receives
Global (G) bit is set from a specified mobile access gateway, the this Binding Revocation Indication message from the specified mobile
local mobility anchor first checks if the mobile access gateway is access gateway, the local mobility anchor first checks if the mobile
authorized to use global revocations and then responds with the access gateway is authorized to use global revocations and if the
appropriate status code by sending a Binding Revocation Acknowledge (A) bit is set, then responds with the appropriate status
Acknowledgement message as in Section 9.2.2. code by sending a Binding Revocation Acknowledgement message as in
Section 8.2.2.
4. Security Model
The binding revocation protocol described here uses the same security
association between the mobile node and the home agent or the mobile
access gateway and the local mobility anchor that has been used to
exchange the corresponding MIPv6 or PMIPv6 Binding Update and Binding
Acknowledgement when the mobile node binding was created. If IPsec
is used, the traffic selectors associated with the SPD entry
protecting the Binding Update and Binding Acknowledgement MUST be
extended to include Binding Revocation Signaling MH type <IANA-TBD>.
Extending the traffic selectors of the SPD entry in order to reuse
the SA protecting Binding Update and Binding Acknowledgement (instead
of creating new ones) ensures that those SA will be up and running
when the revoking entity needs to send a binding revocation signaling
message.
Additionally, in the case when the local mobility anchor receives a
Binding Revocation Indication which indicates a bulk termination
where the Global (G) bit is set and the Revocation Trigger field is
set to "Per-Peer Policy", the local mobility anchor MUST verify that
the mobile access gateway sending the binding revocation indication
message is authorized to invoke global revocation.
5. Binding Revocation Messages over IPv4 Transport Network 4. Binding Revocation Messages over IPv4 Transport Network
In some deployments, the network between the mobile access gateway In some deployments, the network between the mobile access gateway
and the local mobility anchor may only support IPv4 transport. and the local mobility anchor may only support IPv4 transport.
Another case is when a mobile node which supports client mobile IPv6 Another case is when a mobile node which supports client mobile IPv6
roams to an access network where only IPv4 addressing and transport roams to an access network where only IPv4 addressing and transport
is supported. In this case, the mobile node is required to register is supported. In this case, the mobile node is required to register
an IPv4 home address with its home agent using a mobile IPv6 Binding an IPv4 home address with its home agent using a mobile IPv6 Binding
Update message. Update message.
If the Proxy Binding Update and Proxy Binding Acknowledgement If the Proxy Binding Update and Proxy Binding Acknowledgement
messages or the Binding Update and Binding Acknowledgement messages messages or the Binding Update and Binding Acknowledgement messages
are sent using UDP encapsulation to traverse NATs, then the Binding are sent using UDP encapsulation [ID-PMIP6-IPv4] and [RFC5555] to
Revocation messages are sent using the same UDP encapsulation. The traverse NATs, then the Binding Revocation messages are sent using
same UDP source and destination port numbers and IPv4 addresses used the same UDP encapsulation. The same UDP source and destination port
for exchanging the Proxy Binding Update and Proxy Binding numbers and IPv4 addresses used for exchanging the Proxy Binding
Acknowledgement or the Binding Update and Binding Acknowledgement Update and Proxy Binding Acknowledgement or the Binding Update and
messages will also be used when transporting Binding Revocation Binding Acknowledgement messages MUST be used when transporting
messages over IPv4 using UDP encapsulation. For example, the source Binding Revocation messages over IPv4 using UDP encapsulation. For
UDP port number, the destination UDP port number, the source IPv4 example, the source UDP port number, the destination UDP port number,
address, and the destination IPv4 address of the Binding Revocation the source IPv4 address, and the destination IPv4 address of the
Indication message MUST be set to the destination UDP port number, Binding Revocation Indication message are set to the destination UDP
the source UDP port number, destination IPv4 address, and source IPv4 port number, the source UDP port number, destination IPv4 address,
address of the latest successfully processed Proxy Binding Update or and source IPv4 address of the latest successfully processed Proxy
Binding Update message received, respectively. For more details on Binding Update or Binding Update message received, respectively. For
tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling
IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively. messages over IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively.
6. Binding Revocation Message 5. 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 Binding Revocation Indication or Binding Revocation is a Binding Revocation Indication or Binding Revocation
Acknowledgement. If the Binding Revocation type field is set to 1, Acknowledgement. If the Binding Revocation type field is set to 1,
the Binding Revocation Message is a Binding Revocation Indication as the Binding Revocation Message is a Binding Revocation Indication as
in Section 6.1. However, if the value is 2, it is a Binding in Section 5.1. However, if the value is 2, it is a Binding
Revocation Acknowledgement message as in Section 6.2. Revocation Acknowledgement message as in Section 5.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 .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Revocation Message Figure 4: Binding Revocation Message
Payload Proto
8-bit selector. see [RFC3775] for more details.
Header Len
8-bit unsigned integer. representing the length of the Mobility
Header in units of 8 octets, excluding the first 8 octets. see
[RFC3775] for more details.
MH Type MH Type
<IANA-TBD> which identifies the mobility message as a Binding <IANA-TBD> which identifies the mobility message as a Binding
Revocation message. Revocation message.
Reserved Reserved
8-bit field reserved for future use. The value MUST be 8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the initialized to zero by the sender, and MUST be ignored by the
receiver. receiver.
skipping to change at page 14, line 28 skipping to change at page 14, line 22
1 Binding Revocation Indication Message 1 Binding Revocation Indication Message
2 Binding Revocation Acknowledgement Message 2 Binding Revocation Acknowledgement Message
All other values are reserved All other values are reserved
Binding Revocation Message Data Binding Revocation Message Data
The Binding Revocation Message Data follows the Binding Revocation The Binding Revocation Message Data follows the Binding Revocation
Message format that is defined in this document for the specified Message format that is defined in this document for the specified
value in the Binding Revocation Type field. In this value in the Binding Revocation Type field. In this
specification, it is either a Binding Revocation Indication as in specification, it is either a Binding Revocation Indication as in
Section 6.1 or Binding Revocation Acknowledgement as in Section 5.1 or Binding Revocation Acknowledgement as in
Section 6.2. Section 5.2.
6.1. Binding Revocation Indication Message 5.1. Binding Revocation Indication Message
The Binding Revocation Indication (BRI) message is a Binding The Binding Revocation Indication (BRI) message is a Binding
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 of the identity of a specific to inform the receiving mobility entity of the identity of a specific
binding or bindings which IP mobility service have been revoked. binding or bindings which IP mobility service have been revoked.
Binding Revocation Indication message is sent as described in Binding Revocation Indication message is sent as described in
Section 8.1, Section 9.1.1, and Section 10.2.1. Section 7.1, Section 8.1.1, and Section 9.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 # |A|P|V|G| Reserved | | Sequence # |P|V|G|A| 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 Reserved and Per-MN revoking node to send the BRI message. The Reserved and Per-MN
Revocation Triggers value are less than 128 except the reserved Revocation Trigger values are less than 128 except the reserved
values 250-255. The per-MN revocation triggers is used when the values 250-255 as listed below. The per-MN revocation trigger
BRI message intends to revoke one or more bindings for the same value is used when the BRI message intends to revoke one or more
mobile node. The Global Revocation Trigger values are greater bindings for the same mobile node. The Global Revocation Trigger
than 128 and less than 250 and used in the BRI message with the values are greater than 128 and less than 250 and used in the BRI
Global (G) bit set for global revocation. The following message with the Global (G) bit set for global revocation. The
Revocation Trigger values are currently defined: following Revocation Trigger values are currently defined:
Reserved and Per-MN Revocation Trigger: Reserved and Per-MN Revocation Trigger:
0 Reserved 0 Reserved
1 Unspecified 1 Unspecified
2 Administrative Reason 2 Administrative Reason
3 Inter-MAG Handover - same Access Type 3 Inter-MAG Handover - same Access Type
4 Inter-MAG Handover - different Access Type 4 Inter-MAG Handover - different Access Type
5 Inter-MAG Handover - Unknown 5 Inter-MAG Handover - Unknown
6 User Initiated Session(s) Termination 6 User Initiated Session(s) Termination
7 Access Network Session(s) Termination 7 Access Network Session(s) Termination
skipping to change at page 16, line 4 skipping to change at page 15, line 32
3 Inter-MAG Handover - same Access Type 3 Inter-MAG Handover - same Access Type
4 Inter-MAG Handover - different Access Type 4 Inter-MAG Handover - different Access Type
5 Inter-MAG Handover - Unknown 5 Inter-MAG Handover - Unknown
6 User Initiated Session(s) Termination 6 User Initiated Session(s) Termination
7 Access Network Session(s) Termination 7 Access Network Session(s) Termination
8 Possible Out-of Sync BCE State 8 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: Global Revocation Trigger:
128 Per-Peer Policy 128 Per-Peer Policy
129 Revoking Mobility Node Local 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. It could be a random number. Binding Revocation Indication. This sequence number could be a
random number. At any time,implementations MUST ensure that there
Acknowledge (A) is no collision between the sequence numbers of all outstanding
Binding Revocation Messages.
The Acknowledge (A) bit is set by the sending mobility node, e.g.
LMA, HA, or MAG, to request a Binding Revocation Acknowledgement
be returned upon receipt of the Binding Revocation Indication as
in Section 8.1, Section 9.1.1, and Section 10.2.1.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set by the sending mobility node to The Proxy Binding (P) bit is set by the sending mobility node to
indicate that the revoked binding(s) is a PMIPv6 binding. indicate that the revoked binding(s) is a PMIPv6 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, home agent or local mobility anchor, to request the node, home agent or local mobility anchor, to indicate to the
receiving mobility entity the termination of the IPv4 Home Address receiving mobility entity the termination of the IPv4 Home Address
binding only as in Section 8.1, and Section 9.1.1. binding only as in Section 7.1, and Section 8.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
MAG, to request the termination of all Per-Peer mobility Bindings MAG, to indicate the termination of all Per-Peer mobility Bindings
or Multiple Bindings which share a common identifier that are or Multiple Bindings which share a common identifier that are
served by the sending and receiving mobility entities as in served by the sending and receiving mobility entities as in
Section 9.1.1 and Section 10.2.1. Section 8.1.1 and Section 9.2.1.
Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobility node, e.g.
LMA, HA, or MAG, to request a Binding Revocation Acknowledgement
be returned upon receipt of the Binding Revocation Indication as
in Section 7.1, Section 8.1.1, and Section 9.2.1. If Acknowledge
(A) bit is set in the BRI message, the sending mobility node
follows section Section 6.3 for retransmitting the BRI message.
Reserved Reserved
These fields are unused. They MUST be initialized to zero by the These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
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. This document contains zero or more TLV-encoded mobility options. This document
does not define any new mobility option. The receiver MUST ignore does not define any new mobility option. The receiver MUST ignore
and skip any options which it does not understand. These mobility and skip any options which it does not understand. These mobility
option(s) are used by the receiving mobility entity to identify option(s) are used by the receiving mobility entity to identify
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 only when the (P) bit is set. This option MUST be present when
is used to revoke a single PMIP binding cache entry. the BRI is used to revoke a single Proxy MIPv6 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 Global (G) bit is when the (P) bit is set. Additionally, if the Global (G) bit is
set by the mobile access gateway, this option carries the MAG set by the mobile access gateway, this option carries the MAG
identity. identity. In this specification, only Mobile Node Identifier
option with subtype 1 is required and other subtypes are currently
not supported.
o Binding Identifier mobility option [ID-MCoA]. This option is o Binding Identifier mobility option [ID-MCoA]. This option is
mandatory if the sending mobility entity requests to terminate one mandatory if the sending mobility entity requests to terminate one
binding of a multi care-of addresses bindings for the same mobile binding of a multi care-of addresses bindings for the same mobile
node. The sending mobility entity may include more than one of node. The sending mobility entity may include more than one of
the BID mobility options. the BID 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 [RFC5555]. This option is included only when the IPv4 HoA address [RFC5555]. This option is included only when the IPv4 HoA
Binding only (V) bit is set. Binding only (V) bit is set.
o Alternate Care-of Address mobility option [RFC3775]. This option o Alternate Care-of Address mobility option [RFC3775]. This option
MAY be included to indicate the Care-of Address of the mobile MAY be included to indicate the Care-of Address of the mobile
node's binding that is being revoked. In the case when the Global node's binding that is being revoked. In the case when the Global
(G) bit set, this option identifies all the mobility bindings that (G) bit set, this option identifies all the mobility bindings that
share the same care-of address. Additionally, if the Global (G) share the same care-of address. Additionally, if the Global (G)
bit set, more than one Alternate Care-of Address mobility options bit set, more than one Alternate Care-of Address mobility options
MAY be present in the Binding Revocation Indication message. MAY be present in the Binding Revocation Indication message.
If no options are present in this message, 4 octets of padding are If no mobility options are present in this message, 4 octets of
necessary and the Header Len field of the Binding Revocation Message padding are necessary and the Header Len field of the Binding
will be set to 1. Revocation Message will be set to 1.
6.2. Binding Revocation Acknowledgement Message 5.2. Binding Revocation Acknowledgement Message
The Binding Revocation Acknowledgement (BRA) message is a Binding The Binding Revocation Acknowledgement (BRA) message is a Binding
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 2. It is used to acknowledge the receipt of Revocation Type value of 2. It is used to acknowledge the receipt of
a Binding Revocation Indication message described in Section 6.1. a Binding Revocation Indication message described in Section 5.1.
This packet is sent as described in Section 9.2.2, Section 10.1.2, This packet is sent as described in Section 8.2.2, Section 9.1.2, and
and Section 11.2. Section 10.2.
When the value 2 is indicated in the Binding Revocation type field of When the value 2 is indicated in the Binding Revocation type field of
the Binding Revocation Message, the format of the Binding Revocation the Binding Revocation Message, the format of the Binding Revocation
Message Data follows the Binding Revocation Acknowledgement message Message Data follows the Binding Revocation Acknowledgement message
as in Figure 6 as in Figure 6
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 = 2 | Status | | B.R. Type = 2 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |P|V|G| Reserved | | Sequence # |P|V|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
skipping to change at page 19, line 45 skipping to change at page 19, line 38
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 mobility 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. only 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 Identifier mobility option [ID-MCoA]. This option MAY be o Binding Identifier mobility option [ID-MCoA]. This option MAY be
included to indicate the specific BID that the receiving node included to indicate the specific BID that the receiving node
failed to revoke. failed to revoke.
If no options are present in this message, 4 octets of padding are If no options are present in this message, 4 octets of padding are
necessary and the Header Len field of the Binding Revocation Message necessary and the Header Len field of the Binding Revocation Message
will be set to 1. will be set to 1.
7. Binding Revocation Process Operation 6. Binding Revocation Process Operation
The following subsections describe the details of the binding The following subsections describe the details of the generic binding
revocation generic process by the different mobility entities. revocation process as used by the different mobility entities.
7.1. Sending Binding Revocation Messages 6.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, constructs the packet as it would any other Mobility initiator, constructs the packet as it would any other Mobility
Header with the exception of setting the MH Type field to <IANA-TBD>. Header with the exception of setting the MH Type field to <IANA-TBD>.
In addition, the mobility entity which initiates the binding In addition, the initiator, MUST construct the Binding Revocation
revocation process by sending a Binding Revocation Indication Message Data following the format of the Binding Revocation
message, initiator, MUST construct the Binding Revocation Message Indication message as described in Section 5.1. In the BRI message,
Data following the format of the Binding Revocation Indication the initiator MUST set the Sequence Number field to a valid sequence
message as described in Section 6.1. In the BRI message, the number for Binding Revocation. Since sending Binding Revocation
initiator MUST set the Sequence Number field to the next sequence Indication message is not done on a regular basis, a 16 bit sequence
number available for Binding Revocation. Since sending Binding number field is large enough to allow the initiator to match the
Revocation Indication message is not done on a regular basis, a 16 Binding Revocation Acknowledgement to the associated Binding
bit sequence number field is large enough to allow the initiator to Revocation Indication using the sequence number field only.
match the Binding Revocation Acknowledgement to the outstanding
Binding Revocation Indication with Acknowledge (A) bit set using the
sequence number field only.
However, when the responder acknowledges the Binding Revocation However, when the responder acknowledges the Binding Revocation
Indication message, the responder MUST constructs the Binding Indication message, the responder MUST construct the Binding
Revocation message packet as it would any other Mobility Header with Revocation message packet as it would any other Mobility Header with
the exception of setting the MH Type field to <IANA-TBD>. It also the exception of setting the MH Type field to <IANA-TBD>. It also
MUST construct the Binding Revocation Message Data following the MUST construct the Binding Revocation Message Data following the
format of the Binding Revocation Acknowledgement message as described format of the Binding Revocation Acknowledgement message as described
in Section 6.2. In this case, the responder MUST set the Sequence in Section 5.2. In this case, the responder MUST set the Sequence
Number field by copying the value from the Sequence Number field of Number field by copying the value from the Sequence Number field of
the received Binding Revocation Indication. Additionally, it MUST the received Binding Revocation Indication. Additionally, it MUST
set the status field to a valid value that reflects the processing of set the status field to a valid value that reflects the processing of
the received Binding Revocation Indication. the received Binding Revocation Indication.
A mobility entity MUST secure Binding Revocation Indication and The Binding Revocation Indication and Binding Revocation
Binding Revocation Acknowledgement messages with the same underlying Acknowledgement messages MUST be protected using the same underlying
security association, e.g., IPsec SA, that has been used to secure security association, e.g., IPsec, that is being used between the two
the mobile node binding registration signaling. peers to protect the mobile node's Mobile IPv6 and its extensions
binding registration signaling. If IPsec is not used as the
underlying security mechanism to protect the binding registration
signaling, the used underlying security mechanism MUST provide
protection against all identified security threats as described under
Security Considerations in [RFC3775] and [RFC5213].
7.2. Receiving Binding Revocation Messages 6.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 described in section 9.2. of node MUST verify the Mobility Header as described in section 9.2. of
[RFC3775]. If the packet is dropped due to failing any of the [RFC3775]. If the packet is dropped due to failing any of the
Mobility Headers test check, the receiving node MUST follow the Mobility Headers test check, the receiving node MUST follow the
processing rules as in Section 9.2 of [RFC3775]. If the receiving processing rules as in Section 9.2 of [RFC3775]. If the receiving
node does not support the Binding Revocation Indication message and node does not support the Binding Revocation Indication message and
does not recognize the new MH type, it sends a Binding Error message does not recognize the new MH type, it sends a Binding Error message
with the Status field set to 2 as described in [RFC3775]. with the Status field set to 2 as described in [RFC3775].
Since some mobility entities, e.g., local mobility anchor and mobile Since some mobility entities, e.g., local mobility anchor and mobile
access gateway, are allowed to receive and possibly send a Binding access gateway, are allowed to send Binding Revocation Indication and
Revocation Indication or Binding Revocation Acknowledgement for receive Binding Revocation Acknowledgement for different cases,
different cases, therefore, if IPsec is used to secure signaling therefore, if IPsec is used to secure signaling between the local
between the local mobility anchor and mobile access gateway, it mobility anchor and mobile access gateway, it prevents any of them
prevents any of them from processing a Binding Revocation message from processing a Binding Revocation message that was not constructed
that was not constructed by an authorized party. by an authorized party.
Upon receiving a packet carrying a Binding Revocation Indication or Upon receiving a packet carrying a Binding Revocation Indication or
Binding Revocation Acknowledgement, the receiving mobility entity Binding Revocation Acknowledgement, the receiving mobility entity
verifies that the packet was received protected with the security MUST verify that the packet was received protected by the security
association that has been used during the binding registration association that is being used to protect the binding registration
signaling phase, e.g., an IPsec SA. and Binding Revocation signaling between the two peers, e.g., an
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 in the Sequence Number field matches validate that sequence number in the Sequence Number field matches
the sequence number of an outstanding Binding Revocation Indication the sequence number of an outstanding Binding Revocation Indication
that was sent by the initiator. If the sequence number does not that was sent by the initiator. If the sequence number does not
match any sequence number of any of the outstanding Binding match any sequence number of any of the outstanding Binding
Revocation Indication, the receiving node MUST silently discard the Revocation Indication, the receiving node MUST silently discard the
message but MAY log the event. message but MAY log the event.
If a mobility node receives a Binding Revocation Indication message If a mobility node receives a Binding Revocation Indication message
with the Revocation Trigger field is set to a value that NOT with the Revocation Trigger field is set to a value that the mobility
supported, the receiving mobility node SHOULD reject the Binding node does not support and the Acknowledge (A) bit is set, the
Revocation Indication message by sending a Binding Revocation receiving mobility node SHOULD reject the Binding Revocation
Acknowledgement message with the Status field set to "Revocation Indication message by sending a Binding Revocation Acknowledgement
Trigger NOT Supported". message with the Status field set to "Revocation Trigger NOT
Supported".
If a mobility node receives a Binding Revocation Indication message If a mobility node receives a Binding Revocation Indication message
with a Revocation Trigger value that is NOT in line with the Binding with a Revocation Trigger value that is NOT allowed with the Binding
Revocation Indication message intent, e.g., the Global (G) bit set Revocation Indication message intent, e.g., the Global (G) bit set
and the Revocation Trigger field vale is a per-MN specific, the and the Revocation Trigger field vale is a per-MN specific, the
receiving mobility node SHOULD reject the Binding Revocation receiving mobility node SHOULD reject the Binding Revocation
Indication message by sending a Binding Revocation Acknowledgement Indication message by sending a Binding Revocation Acknowledgement
message with the Status field set to "Revocation Function NOT message with the Status field set to "Revocation Function NOT
Supported". Supported".
7.3. Retransmission of Binding Revocation Indication 6.3. Retransmission of Binding Revocation Indication
If the sending mobility entity does not receive a Binding Revocation If the sending mobility entity set the Acknowledge (A) bit in the BRI
Acknowledgement in response to the outstanding initial Binding and does not receive a Binding Revocation Acknowledgement in response
Revocation Indication before the InitMINDelayBRIs timer expires, the to the outstanding Binding Revocation Indication before the
mobility entity, e.g. LMA, SHOULD retransmit the same BRI message up InitMINDelayBRIs timer expires, the mobility entity, e.g. LMA,
to the BRIMaxRetriesNumber as defined in Section 12. SHOULD retransmit the same BRI message up to the BRIMaxRetriesNumber
as defined in Section 11. However, if the sending mobility entity
does not set the Acknowledge (A) bit in the BRI, the sending mobility
entity SHOULD NOT retransmit the Binding Revocation Indication
message.
The retransmissions by the sending mobility entity MUST use an The retransmissions by the sending mobility entity MUST use an
exponential back-off process in which the timeout period is doubled exponential back-off process in which the timeout period is doubled
upon each retransmission, until either the node receives a response upon each retransmission, until either the node receives a response
or the timeout period reaches the value MAX_BRACK_TIMEOUT. The or the timeout period reaches the value MAX_BRACK_TIMEOUT. The
sending mobility entity MAY continue to send these messages at this sending mobility entity MAY continue to send these messages at this
slower rate up to the BRIMaxRetriesNumber. slower rate up to the BRIMaxRetriesNumber.
If the revoking mobility entity does not receive a Binding Revocation If the revoking mobility entity does not receive a Binding Revocation
Acknowledgement message after the maximum number of retransmits have Acknowledgement message after the BRIMaxRetriesNumber of retransmits
been sent, the revoking mobility entity can clean the mobile node have been sent, the revoking mobility entity can clean the mobile
binding cache and all resources associated with this binding. The node binding cache and all resources associated with this binding.
revoking mobility entity may log the event. The revoking mobility entity may log the event.
8. Home Agent Operation 7. Home Agent Operation
8.1. Sending Binding Revocation Indication 7.1. Sending Binding Revocation Indication
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 to request the mobile node to o The Acknowledge (A) bit MAY be set to request the mobile node to
send a Binding Revocation Acknowledgement upon receipt of the send a Binding Revocation Acknowledgement upon receipt of the
Binding Revocation Indication. Binding Revocation Indication.
skipping to change at page 23, line 17 skipping to change at page 23, line 17
agent. The Revocation Trigger may be used by the mobile node to agent. The Revocation Trigger may be used by the mobile node to
take further steps if necessary. take further steps if 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. If an Alternate Care-of Address
option is included in the Binding Revocation Indication message,
the destination address in the packet's IPv6 header SHOULD be set
to the source IP address of the packet that carried the latest
successful Binding Update with the Alternate Care-of address
included.
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
(V) bit and MUST include the mobile node's registered IPv4 home (V) bit and MUST include the mobile node's registered IPv4 home
address that is being revoked in the IPv4 Home Address option. address that is being revoked in the IPv4 Home Address option.
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the mobile node to return a Binding Revocation Acknowledgement in the mobile node to return a Binding Revocation Acknowledgement in
response to this Binding Revocation Indication. As described in response to this Binding Revocation Indication. As described in
Section 7.3, the home agent SHOULD retransmit this Binding Revocation Section 6.3, the home agent SHOULD retransmit this Binding Revocation
Indication to the mobile node before terminating its IP connection Indication to the mobile node before terminating its IP connection
until it receives a matching Binding Revocation Acknowledgement or until it receives a matching Binding Revocation Acknowledgement or
the BRIMaxRetransmitNumber has been reached. the BRIMaxRetransmitNumber has been reached.
When the home agent sends a Binding Revocation Indication to the When the home agent sends a Binding Revocation Indication to the
mobile node with the Acknowledge (A) bit set, the home agent sets a mobile node with the Acknowledge (A) bit set, the home agent sets a
flag in the mobile node BCE to indicate that revocation is in flag in the mobile node BCE to indicate that revocation is in
progress and starts the InitMINDelayBRIs timer. The home agent progress and starts the InitMINDelayBRIs timer. The home agent
maintains the mobile node BCE in this state until it receives a maintains the mobile node BCE in this state until it receives a
Binding Revocation Acknowledgement or retransmits the Binding Binding Revocation Acknowledgement or retransmits the Binding
Revocation Indication message as described in Section 7.3. Revocation Indication message as described in Section 6.3.
In a race condition case, the home agent may receive a Binding Update In a race condition case, the home agent may receive a Binding Update
from the mobile node while the mobile node's BCE has the revocation from the mobile node while the mobile node's BCE has the revocation
in progress flag set, the home agent SHOULD handle this case based on in 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 its local policy. In this case, if the home agent accepts the
Binding Update, it needs to update the mobile node BCE accordingly, Binding Update, it needs to update the mobile node BCE accordingly,
e.g. removing the revocation in progress flag. e.g. removing the 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 BID as in [ID-MCoA], the home agent MUST include all the related BID
mobility options that identify these bindings in the Binding mobility options that identify these bindings in the Binding
Revocation Indication message. In the case when the home agent needs Revocation Indication message. In the case when the home agent needs
to revoke all of the mobile node bindings, the home agent SHOULD NOT to revoke all of the mobile node bindings, the home agent SHOULD NOT
include any of the BID mobility options. include any of the BID mobility options.
8.2. Receiving Binding Revocation Acknowledgement 7.2. Receiving Binding Revocation Acknowledgement
When the home agent receives a packet carrying a valid Binding When the home agent receives a packet carrying a valid Binding
Revocation Acknowledgement that was successfully processed as in Revocation Acknowledgement that was successfully processed as in
Section 7.2, the home agent SHOULD examine the Status field as Section 6.2, the home agent SHOULD examine the Status field as
follows: 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 MUST delete Indication was processed successfully, the home agent MUST delete
the current timer and the mobile node bindings and all related the current timer and the mobile node bindings and all related
resources. resources.
o If the Status field indicates any value other than success, the o If the Status field indicates any value other than success, the
home agent SHOULD examine any mobility options included in the home agent SHOULD examine any mobility options included in the
Binding Revocation Acknowledgement. In this case, it is based on Binding Revocation Acknowledgement. In this case, it is based on
the home agent local policy how to handle the mobile node BCE. the home agent local policy how to handle the mobile node BCE.
The home agent MAY log the appropriate event to reflect the The home agent MAY log the appropriate event to reflect the
received status. received status.
9. Local Mobility Anchor Operation 8. Local Mobility Anchor Operation
9.1. Binding Revocation Initiator 8.1. Binding Revocation Initiator
9.1.1. Sending Binding Revocation Indication 8.1.1. Sending Binding Revocation Indication
To terminate a mobile node PMIPv6 registration and its current To terminate a mobile node PMIPv6 registration and its current
binding with the local mobility anchor, the local mobility anchor binding with the local mobility anchor, the local mobility anchor
sends a packet to the mobile access gateway containing a Binding sends a packet to the mobile access gateway containing a Binding
Revocation Indication message following the procedure in Section 7.1 Revocation Indication message following the procedure in Section 6.1
and the following rules: and the following rules:
o The Acknowledge (A) bit MAY be set to request the mobile access o The Acknowledge (A) bit MAY be set to request the mobile access
gateway to send a Binding Revocation Acknowledgement upon receipt gateway to send a Binding Revocation Acknowledgement upon receipt
of the Binding Revocation Indication. of the Binding Revocation Indication.
o The Proxy Mobile IP (P) bit MUST be set to indicate that the o The Proxy Mobile IP (P) bit MUST be set to indicate that the
binding being revoked is a PMIPv6 binding. binding being revoked is a PMIPv6 binding.
o The Revocation Trigger field MUST be set to indicate to the mobile o The Revocation Trigger field MUST be set to indicate to the mobile
access gateway the reason for removing the specified mobile node access gateway the reason for removing the specified mobile node
PMIPv6 binding at the local mobility anchor. The Revocation PMIPv6 binding at the local mobility anchor. The Revocation
Trigger may be used by the mobile access gateway to learn the Trigger may be used by the mobile access gateway to learn the
mobile node's latest movement. mobile node's latest movement.
o The packet MUST contain the Mobile Node Identifier, MN-ID, option
which contains the mobile node's NAI that was used in the Proxy
Binding Update during the mobile node registration.
o If the Mobile Node Identifier, MN-ID, is registered in more than
one of the mobile node's BCE and the local mobility anchor does
NOT need to revoke all of the mobile node's bindings, the Binding
Revocation Indication message MUST contain another identifier to
uniquely identify the mobile node binding(s) that is being
revoked, e.g., at least one Home Network Prefix option which
contains the mobile node's registered Home Network Prefix (HNP)
for the binding being revoked.
o In case of revoking all Per-Peer bindings, the Global (G) bit MUST o In case of revoking all Per-Peer bindings, the Global (G) bit MUST
be set and the Revocation Trigger MUST contain a value of "Per- be set and the Revocation Trigger MUST contain a value of "Per-
Peer Policy" to request the mobile access gateway to remove all Peer Policy" to request the mobile access gateway to remove all
Per-Peer bindings that are registered with the local mobility Per-Peer bindings that are registered with the local mobility
anchor and hosted at this mobile access gateway. anchor and this mobile access gateway.
o Whenever the Global (G) bit is set in the Binding Revocation o Whenever the Global (G) bit is set in the Binding Revocation
Indication, the Acknowledge (A) bit MUST be set to request the Indication, the Acknowledge (A) bit MUST be set to request the
mobile access gateway to send a Binding Revocation mobile access gateway to send a Binding Revocation
Acknowledgement. Acknowledgement.
o The packet MUST contain the Mobile Node Identifier, MN-ID, option
which contains the mobile node's NAI that was used in the Proxy
Binding Update during the mobile node registration.
o If the Mobile Node Identifier, MN-ID, is registered in more than
one of the mobile node's BCE and the local mobility anchor does
NOT need to revoke all of the mobile node's bindings, the packet
MUST contain another identifier to uniquely identify the mobile
node binding(s) that is being revoked, e.g., at least one Home
Network Prefix option which contains the mobile node's registered
HNP for the binding being revoked.
o The care-of address for the binding 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 message. Binding Revocation Indication message. If an Alternate Care-of
Address option is included in the Binding Revocation Indication
message, the destination address in the packet's IPv6 header
SHOULD be set to the source IP address of the packet that carried
the latest successful Binding Update with the Alternate Care-of
address included.
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the mobile access gateway to return a Binding Revocation the mobile access gateway to return a Binding Revocation
Acknowledgement. As described in Section 7.3, the local mobility Acknowledgement. If the local mobility anchor set the Acknowledge
anchor SHOULD retransmit this Binding Revocation Indication before (A) bit in the Binding Revocation Indication message, the local
deleting the mobile node IP tunnel to the mobile access gateway until mobility anchor SHOULD retransmit Binding Revocation Indication
it receives a matching Binding Revocation Acknowledgement or the message by following the procedure described in Section 6.3 until it
BRIMaxRetransmitNumber is reached. The local mobility anchor MAY receives a matching Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached before deleting the mobile node IP
tunnel to the mobile access gateway. The local mobility anchor MAY
delete the mobile node(s) IP tunnel immediately after sending the delete the mobile node(s) IP tunnel immediately after sending the
Binding Revocation Indication and before receiving the Binding initial Binding Revocation Indication and before receiving the
Revocation Acknowledgement message. Binding Revocation Acknowledgement message.
When the local mobility anchor sends a Binding Revocation Indication When the local mobility anchor sends a Binding Revocation Indication
to the mobile access gateway to remove a specific binding and the to the mobile access gateway to remove a specific binding and the
Acknowledge (A) bit is set, the local mobility anchor sets a flag in Acknowledge (A) bit is set, the local mobility anchor sets a flag in
the mobile node proxy BCE to indicate that revocation is in progress the mobile node proxy BCE to indicate that revocation is in progress
and starts the InitMINDelayBRIs timer. The local mobility anchor and starts the InitMINDelayBRIs timer. The local mobility anchor
SHOULD maintain the mobile node proxy BCE in this state until it SHOULD maintain the mobile node proxy BCE in this state until it
receives a Binding Revocation Acknowledgement or the receives a Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached. In the case when the local BRIMaxRetransmitNumber is reached. In the case when the local
mobility anchor sets the Revocation Trigger field to a value which mobility anchor sets the Revocation Trigger field to a value which
skipping to change at page 26, line 19 skipping to change at page 26, line 33
In a race condition case, the local mobility anchor may receive a In a race condition case, the local mobility anchor may receive a
Proxy Binding Update from the mobile access gateway while the mobile Proxy Binding Update from the mobile access gateway while the mobile
node's proxy BCE has the revocation in progress flag set, the local node's proxy BCE has the revocation in progress flag set, the local
mobility anchor should handle this case based on the reason for mobility anchor should handle this case based on the reason for
sending the Binding Revocation Indication message and its local sending the Binding Revocation Indication message and its local
policy. In this case, if the local mobility anchor accepts the Proxy policy. In this case, if the local mobility anchor accepts the Proxy
Binding Update, it needs to update the mobile node proxy BCE Binding Update, it needs to update the mobile node proxy BCE
accordingly, e.g. removing the revocation in progress flag. accordingly, e.g. removing the revocation in progress flag.
When the local mobility anchor needs to revoke all mobile nodes proxy When the local mobility anchor needs to revoke all the mobile nodes
BCE that are registered with the local mobility anchor and hosted at proxy BCEs that are registered with the local mobility anchor and the
the mobile access gateway, it MUST set the Global (G) bit and set the mobile access gateway, it MUST set the Global (G) bit and set the
value of the Revocation Trigger field to "Per-Peer Policy". In this value of the Revocation Trigger field to "Per-Peer Policy". In this
case, the local mobility anchor MUST NOT include any mobility options case, the local mobility anchor MUST NOT include any mobility options
in the this Binding Revocation Indication message. in the this Binding Revocation Indication message.
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 belong to a specific realm, e.g. @example.com, that are BCEs that belong to a specific realm and are registered with the
registered with the local mobility anchor and hosted at the mobile local mobility anchor and the mobile access gateway, the local
access gateway, the local mobility anchor MUST set the Global (G) bit mobility anchor MUST set the Global (G) bit and set the value of the
and set the value of the Revocation Trigger field to "Revoking Revocation Trigger field to "Revoking Mobility Node Local Policy".
Mobility Node Local Policy". In this case, the local mobility anchor In this case, the local mobility anchor MUST include a mobility
MUST include a mobility option in the Binding Revocation Indication option in the Binding Revocation Indication that is shared among all
to identify the impacted bindings, e.g., MN-ID option with an NAI the impacted mobile nodes BCEs, e.g., the mobile node identifier
value of @example.com, to identify all the mobile nodes BCEs that option, MN-ID option, with subtype value of 1. In this case, the NAI
have a MN-ID with a realm that matches the NAI value in the received value in the MN-ID MUST follow the format where the content after the
MN-ID option and need to be removed. "@" character defines the realm which is shared amongst all of the
impacted mobile nodes proxy BCEs. As an example: @example.one.com
identifies all mobile nodes which their MN-ID value contain
"example.one.com as the realm, e.g., "1234abdelta@example.one.come"
and "axxxyzd@example.one.com, and abcdefg.xyz123@example.one.com.
When the local mobility anchor needs to revoke a subgroup of the
mobile nodes proxy BCEs that belong to a specific realm and are
registered with the local mobility anchor and the mobile access
gateway, the local mobility anchor MUST set the Global (G) bit and
set the value of the Revocation Trigger field to "Revoking Mobility
Node Local Policy". In this case, the local mobility anchor MUST
include an additional mobility option to the mobile node identifier
option, MN-ID option, with subtype value of 1. In other words, the
impacted mobile node BCEs are those which have a MN-ID with a realm
as specified above and is assigned the same proxy care-of address as
the one included in the Alternate Care-of address mobility option.
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
Binding Revocation Indication. Alternatively, it MAY include only Binding Revocation Indication. Alternatively, it MAY include only
the mobile node identifier, MN-ID, option to indicate to the mobile the mobile node identifier, MN-ID, option with the mobile node NAI
access gateway to remove all bindings of the specified mobile node included to indicate to the mobile access gateway to remove all
NAI in the MN-ID option. bindings of the specified mobile node NAI in the MN-ID option.
According to Proxy Mobile IPv6 specification [RFC5213], if the local According to Proxy Mobile IPv6 specification [RFC5213], if the local
mobility anchor receives a Proxy Binding Update message from a new mobility anchor receives a Proxy Binding Update message from a new
mobile access gateway for extending the binding lifetime of the only mobile access gateway for extending the binding lifetime of the only
BCE of this mobile node with the Handoff Indicator value is set to BCE of this mobile node with the Handoff Indicator value is set to
"Inter-MAG Handover - Unknown", the local mobility anchor waits a "Inter-MAG Handover - Unknown", the local mobility anchor waits a
period of MaxDelayBeforeNewBCEAssign to receive a de-registration period of MaxDelayBeforeNewBCEAssign to receive a de-registration
message from the previous mobile access gateway before updating the message from the previous mobile access gateway before updating the
mobile node's BCE with the new point of attachment. If a de- mobile node's BCE with the new point of attachment. If a de-
registration message is not received,, the local mobility anchor registration message is not received,, the local mobility anchor
skipping to change at page 27, line 44 skipping to change at page 28, line 28
Acknowledgement message with the status field set to "Revocation Acknowledgement message with the status field set to "Revocation
Failed - MN is Attached", the local mobility anchor SHOULD update Failed - MN is Attached", the local mobility anchor SHOULD update
the mobile node BCE in a similar way as if it did NOT receive a the mobile node BCE in a similar way as if it did NOT receive a
de-registration before the MaxDelayBeforeNewBCEAssign timer de-registration before the MaxDelayBeforeNewBCEAssign timer
expires by creating a new BCE as described in [RFC5213]. expires by creating a new BCE as described in [RFC5213].
o If the local mobility anchor did not receive a Binding Revocation o If the local mobility anchor did not receive a Binding Revocation
Acknowledgement message nor a de-registration Proxy Binding Update Acknowledgement message nor a de-registration Proxy Binding Update
from the previous mobile access gateway after it exhausted all of from the previous mobile access gateway after it exhausted all of
the Binding Revocation Indication message retransmissions as the Binding Revocation Indication message retransmissions as
described in Section 7.3, the local mobility anchor SHOULD update described in Section 6.3, the local mobility anchor SHOULD update
the mobile node's BCE in a similar way as if it did NOT receive a the mobile node's BCE in a similar way as if it did NOT receive a
de-registration before the MaxDelayBeforeNewBCEAssign timer de-registration before the MaxDelayBeforeNewBCEAssign timer
expires by creating a new BCE as described in [RFC5213]. Note expires by creating a new BCE as described in [RFC5213]. Note
that the local mobility anchor SHOULD use the recommended number that the local mobility anchor SHOULD use the recommended number
of retransmissions for the Binding Revocation Indication message of retransmissions for the Binding Revocation Indication message
as described in Section 12 to avoid delaying the creation of a new as described in Section 11 to avoid delaying the creation of a new
binding cache entry for too long, if the mobile node is actually binding cache entry for too long, if the mobile node is actually
attaching to the new MAG with a different interface. attaching to the new MAG with a different interface.
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 local mobility anchor decides to revoke the mobile node IPv4 the local mobility anchor decides to revoke the mobile node IPv4
proxy HoA ONLY, it MUST send a Binding Revocation Indication message proxy HoA ONLY, it MUST send a Binding Revocation Indication message
following the procedure in Section 7.1 and the following rules: following the procedure in Section 6.1 and the following rules:
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 to request the mobile access o The Acknowledge (A) bit MUST be set to request the mobile access
gateway to send a Binding Revocation Acknowledgement message. gateway to send a Binding Revocation Acknowledgement 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. "User Initiated Session(s) Termination". e.g. "User Initiated Session(s) Termination".
9.1.2. Receiving Binding Revocation Acknowledgement 8.1.2. Receiving Binding Revocation Acknowledgement
When the local mobility anchor receives a packet carrying a valid When the local mobility anchor receives a packet carrying a valid
Binding Revocation Acknowledgement that was successfully processed as Binding Revocation Acknowledgement that was successfully processed as
in Section 7.2 and if the mobile node BCE is in the state of in Section 6.2 and if the mobile node BCE is in the state of
Revocation in progress, the local mobility anchor SHOULD examine the Revocation in progress, the local mobility anchor SHOULD examine the
Status field before clearing the mobile node related resources as Status field before clearing the mobile node related resources as
follows: follows:
o If the Status field indicates that the BRI was processed o If the Status field indicates that the BRI was processed
successfully, the local mobility anchor MUST delete the current successfully, the local mobility anchor MUST delete the current
timer and the mobile node proxy bindings and all associated timer and the mobile node proxy bindings and all associated
resources. resources.
o If the Status field indicates partial success value or MN binding o If the Status field indicates partial success value or MN binding
does not exist, the local mobility anchor SHOULD examine mobility does not exist, the local mobility anchor SHOULD examine the
options that are included in the Binding Revocation mobility options that are included in the Binding Revocation
Acknowledgement, if any, before deleting the current timer and the Acknowledgement, if any, before deleting the current timer and the
mobile node associated proxy bindings and other related resources. mobile node associated proxy bindings and other related resources.
It is based on the local mobility anchor local policy how to It is based on the local mobility anchor local policy how to
handle the mobile node BCE(s) that the mobile access gateway handle the mobile node BCE(s) that the mobile access gateway
indicated it failed the revocation procedure, however, the LMA MAY indicated it failed the revocation procedure, however, the LMA MAY
log the event. log the event.
9.2. Binding Revocation Responder 8.2. Binding Revocation Responder
9.2.1. Receiving Binding Revocation Indication 8.2.1. Receiving Binding Revocation Indication
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 6.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 Validate that Binding Revocation Indication is formatted as in
if the (P) bit is set, the local mobility anchor MUST validate Section 5.1 and if the (P) bit is set, the local mobility anchor
that all impacted binding(s) have the proxy binding flag set. MUST validate that all impacted binding(s) have the proxy binding
flag set.
o If the Global (G) bit is set and the Revocation Trigger value is o If the Global (G) bit is set and the Revocation Trigger value is
"Per-Peer Policy", the Proxy (P) bit MUST be set and the Binding "Per-Peer Policy", the Proxy (P) bit MUST be set and the Binding
Revocation Indication SHOULD contain the mobile access gateway ID Revocation Indication SHOULD contain the mobile access gateway ID
in the MN-ID option. The local mobility anchor MUST verify that in the MN-ID option. The local mobility anchor MUST verify that
the identified mobile access gateway as per the value in the MN-ID the identified mobile access gateway as per the value in the MN-ID
option is authorized to use the Global revocation. The mechanism option is authorized to use the Global revocation, see section
the local mobility anchor uses to verify the mobile access gateway Section 13.
authorization is out of scope of this document.
o If the Global (G) bit is set and the Revocation Trigger value is o If the Global (G) bit is set and the Revocation Trigger value is
"Per-Peer Policy", and only the mobile node identifier, MN-ID, "Per-Peer Policy", and only the mobile node identifier, MN-ID,
option is included, the local mobility anchor MUST revoke all option is included, the local mobility anchor MUST revoke all
mobile nodes bindings which proxy CoA is the one used as the mobile nodes bindings which proxy CoA is the one used as the
source of the IPv6 packet that carried the Binding Revocation source of the IPv6 packet that carried the Binding Revocation
Indication. However, if one or more Alternate Care-of Address Indication. However, if one or more Alternate Care-of Address
options are included in addition to the mobile node identifier options are included in addition to the mobile node identifier
option, the local mobility anchor MUST revoke all mobile nodes option, the local mobility anchor MUST revoke all mobile nodes
bindings which proxy Care-of Address matches one of the Care-of bindings which proxy Care-of Address matches one of the Care-of
address(es) in the Alternate Care-of Address option(s). address(es) in the Alternate Care-of Address option(s).
o The local mobility anchor identifies all impacted mobile nodes o The local mobility anchor identifies all impacted mobile nodes
bindings and if the Acknowledge (A) bit is set, the local mobility bindings and if the Acknowledge (A) bit is set, the local mobility
anchor MUST send a Binding Revocation Acknowledgement following anchor MUST send a Binding Revocation Acknowledgement following
Section 9.2.2 using the appropriate status code. Section 8.2.2 using the appropriate status code.
o If the Global (G) bit is NOT set, the local mobility anchor SHOULD 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.
3. If the mobile node identifier, MN-ID, option and more than one 3. If the mobile node identifier, MN-ID, option and more than one
Home Network Prefix options are included, the local mobility Home Network Prefix options are included, the local mobility
anchor MUST remove all bindings which are referenced by these anchor MUST remove all bindings which are referenced by these
multiple Home Network Prefixes for the specified mobile node multiple Home Network Prefixes for the specified mobile node
NAI. NAI.
4. If the IPv4 HoA binding Only (V) bit is set and the mobile
node identifier, MN-ID, option and the IPv4 Home Address
option are included, the local mobility anchor MUST remove
only the IPv4 HoA address binding to the mobile node current
proxy Care-of address.
The Revocation Trigger field value in the received Binding Revocation The Revocation Trigger field value in the received Binding Revocation
Indication could be used by the local mobility anchor to log an event Indication could be used by the local mobility anchor to log an event
or update some local parameters which tracks the state of the peer or update some local parameters which tracks the state of the peer
mobile access gateway. mobile access gateway.
9.2.2. Sending Binding Revocation Acknowledgement 8.2.2. Sending Binding Revocation Acknowledgement
When the local mobility anchor receives a valid Binding Revocation When the local mobility anchor receives a valid Binding Revocation
Indication with the Acknowledge (A) bit set and after processing the Indication with the Acknowledge (A) bit set and after processing the
Binding Revocation Indication message, the local mobility anchor Binding Revocation Indication message, the local mobility anchor
sends a packet to the mobile access gateway containing a Binding sends a packet to the mobile access gateway containing a Binding
Revocation Acknowledgement following the process in Section 7.1 and Revocation Acknowledgement following the process in Section 6.1 and
the following: the following:
o If the (P) bit was set in the received Binding Revocation o If the (P) bit was set in the received Binding Revocation
Indication, the local mobility anchor MUST set the (P) bit in the Indication, the local mobility anchor MUST set the (P) bit in the
Binding Revocation Acknowledgement. Binding Revocation Acknowledgement.
o If the Global (G) bit was set in the received Binding Revocation o If the Global (G) bit was set in the received Binding Revocation
Indication, the local mobility anchor MUST set the Global (G) bit Indication, the local mobility anchor MUST set the Global (G) bit
in the Binding Revocation Acknowledgement. in the Binding Revocation Acknowledgement.
o If the IPv4 HoA Binding Only (V) bit was set in the received o If the IPv4 HoA Binding Only (V) bit was set in the received
Binding Revocation Indication, the local mobility anchor MUST set Binding Revocation Indication, the local mobility anchor MUST set
the (V) bit in the Binding Revocation Acknowledgement. the (V) bit in the Binding Revocation Acknowledgement.
o The local mobility anchor MUST set the Status field to a valid o The local mobility anchor MUST set the Status field to a valid
code that reflects the processing of the received Binding code that reflects the processing of the received Binding
Revocation Indication. If the mobile access gateway is not Revocation Indication. If the mobile access gateway is not
authorized to use the Per-Peer Global revocation feature, the authorized to use the Per-Peer Global revocation feature or the
local mobility anchor MUST set the Status field to (Global received Binding Revocation Indication message has the Global (G)
Revocation NOT Authorized). bit set and the Revocation Trigger field is set to "Per-Peer
Policy", but the MN-ID option is not included, the local mobility
anchor MUST set the Status field to (Global Revocation NOT
Authorized).
o In the case that one of the bindings identified in the received o In the case that one of the bindings identified in the received
Binding Revocation Indication message has already been released, Binding Revocation Indication message has already been released,
the local mobility anchor MAY set the Status field to partial the local mobility anchor MAY set the Status field to partial
success and in this case it MAY include the mobile node identifier success and in this case it MAY include the mobile node identifier
or the Home Network Prefix option to identify the binding(s) that or the Home Network Prefix option to identify the binding(s) that
failed revocation. failed revocation.
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. Mobile Access Gateway Operation 9. Mobile Access Gateway Operation
10.1. Binding Revocation Responder 9.1. Binding Revocation Responder
10.1.1. Receiving Binding Revocation Indication 9.1.1. Receiving Binding Revocation Indication
Upon receiving a packet carrying a Binding Revocation Indication, the Upon receiving a packet carrying a Binding Revocation Indication, the
mobile access gateway MUST validate the packet according to mobile access gateway MUST validate the packet according to
Section 7.2 and the following: Section 6.2 and the following:
o Binding Revocation Indication MUST be formatted as in Section 6.1 o Binding Revocation Indication MUST be formatted as in Section 5.1
and the (P) bit is set. and the (P) bit is set.
o If the Acknowledge (A) bit in the received Binding Revocation o If the Acknowledge (A) bit in the received Binding Revocation
Indication is set, the mobile access gateway MUST send a Binding Indication is set, the mobile access gateway MUST send a Binding
Revocation Acknowledgement following Section 10.1.2 using the Revocation Acknowledgement following Section 9.1.2 using the
appropriate status value. appropriate status value.
o If the Global (G) bit is set and the Revocation Trigger field o If the Global (G) bit is set and the Revocation Trigger field
value is "Per-Peer policy", the mobile access gateway identifies value is "Per-Peer policy", the mobile access gateway identifies
all bindings that are registered at the local mobility anchor and all bindings that are registered at the local mobility anchor and
hosted at the mobile access gateway. This Binding Revocation the mobile access gateway. If this Binding Revocation Indication
Indication does not include any other mobility options. In this message does not include any mobility options and the Acknowledge
case, the mobile access gateway MUST send a Binding Revocation (A) bit is set, the mobile access gateway MUST send a successful
Acknowledgement with the appropriate status code to the local Binding Revocation Acknowledgement with the appropriate status
mobility anchor. code to the local mobility anchor. Since such this Binding
Revocation Indication message impacts all the mobility sessions
that are registered with the mobile access gateway and the local
mobility anchor, no mobility option is expected in this Binding
Revocation Indication message. However, if this received Binding
Revocation Indication message includes any mobility option and the
Acknowledge (A) bit set, the mobile access gateway MUST send a
Binding Revocation Acknowledgement with status code set to
"Revocation Function NOT Supported".
o If the Global (G) bit is set and the Revocation Trigger field o If the Global (G) bit is set and the Revocation Trigger field
value is "Revoking Mobility Node Local Policy", the mobile access value is "Revoking Mobility Node Local Policy", the mobile access
gateway MUST identify all bindings that are registered at the gateway MUST identify all bindings that are registered at the
local mobility anchor and hosted at the mobile access gateway local mobility anchor and the mobile access gateway and share the
using the mobility option(s) included in the Binding Revocation criteria based on the mobility option(s) included in the Binding
Indication which SHOULD include at least the MN-ID option, e.g., Revocation Indication. In this case, the mobile access gateway
with a wild card NAI. In this case, the mobile access gateway MUST verify that at least the MN-ID option with the subtype value
MUST send a Binding Revocation Acknowledgement with the of 1 is included in the Binding Revocation Indication and it is
appropriate status code to the local mobility anchor. formatted as specified is section Section 8.1.1. If the mobile
access gateway successfully process the BRI and the Acknowledge
(A) bit is set, the mobile access gateway MUST send a successful
Binding Revocation Acknowledgement with the appropriate status
code to the local mobility anchor.
o If the Global (G) bit is set and the Revocation Trigger field o If the Global (G) bit is set and the Revocation Trigger field
value is "Revoking Mobility Node Local Policy", and no mobility value is "Revoking Mobility Node Local Policy", and no mobility
options are included in the Binding Revocation Indication message options are included in the Binding Revocation Indication message
or the mobile access gateway is not able to identify the impacted or the mobile access gateway is not able to identify the impacted
mobile nodes bindings based on the included mobility options, the mobile nodes bindings based on the included mobility options, the
mobile access gateway MUST treat this as an error scenario. In mobile access gateway MUST treat this as an error scenario. In
this case, the mobile access gateway SHOULD send a Binding this case, the mobile access gateway SHOULD send a Binding
Revocation Acknowledgement message with status "Revoked Mobile Revocation Acknowledgement message with status "Revoked Mobile
Nodes Identity Required". Nodes Identity Required".
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 inter-MAG handover, e.g., Revocation Indication message indicates inter-MAG handover, e.g.,
Inter-MAG Handover - Unknown, and the Acknowledge (A) bit is set, Inter-MAG Handover - Unknown, and the Acknowledge (A) bit is set,
the mobile access gateway uses the mobility option(s) included in the mobile access gateway uses the mobility option(s) included in
the Binding Revocation Indication message to identify the mobile the Binding Revocation Indication message to identify the mobile
node binding. The mobile access gateway SHOULD validate that the node binding. The mobile access gateway SHOULD ensure that the
mobile node is no longer attached to the mobile access gateway mobile node is no longer attached to the mobile access gateway
before sending a successful Binding Revocation Acknowledgement before sending a successful Binding Revocation Acknowledgement
message to the local mobility anchor. However, if the mobile message to the local mobility anchor. However, if the mobile
access gateway verified that the mobile node is still directly access gateway verified that the mobile node is still directly
attached, the mobile access gateway MUST set the status field in attached, the mobile access gateway MUST set the status field in
the Binding Revocation Acknowledgement to "Revocation failed - MN the Binding Revocation Acknowledgement to "Revocation failed - MN
is Attached". is Attached".
o If the IPv4 HoA Binding Only (V) bit in the received Binding o If the IPv4 HoA Binding Only (V) bit in the received Binding
Revocation Indication message is set, the mobile access gateway Revocation Indication message is set, the mobile access gateway
uses the MN-ID option to identify the mobile node binding entry in uses the MN-ID option to identify the mobile node binding entry in
the Binding Update List (BUL). It MUST verify that the IPv4 the Binding Update List (BUL). It 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
Binding Revocation Indication is the same as the IPv4 proxy HoA Binding Revocation Indication is the same as the IPv4 proxy HoA
that is assigned to the mobile node. After the mobile access that is assigned to the mobile node. After the mobile access
gateway successfully validates the received IPv4 home address as gateway successfully validates the received IPv4 home address as
the mobile node IPv4 HoA, it MUST consider this as an indication the mobile node IPv4 HoA, it MUST consider this as an indication
to release the mobile node IPv4 proxy HoA binding to the mobile to ONLY release the mobile node IPv4 proxy HoA binding to the
node current proxy CoA ONLY. Consequently, it MUST continue to mobile node current proxy CoA. Consequently, it MUST continue to
maintain the mobile node IPv6 proxy HoA or HNP binding to the maintain the mobile node IPv6 proxy HoA or HNP binding to the
current mobile node proxy CoA as part of the mobile node binding current mobile node proxy CoA as part of the mobile node binding
in the BUL entry and release all resources associated with the MN in the BUL entry and release all resources associated with the MN
IPv4 proxy HoA binding to the MN pCoA. In this case, the mobile IPv4 proxy HoA binding to the MN pCoA. In this case, if the
access gateway MUST send a Binding Revocation Acknowledgement Acknowledge (A) bit is set, the mobile access gateway MUST send a
message with the Status field is set to success. On the other Binding Revocation Acknowledgement message with the Status field
hand, if the mobile access gateway is able to identify the mobile is set to success. On the other hand, if the mobile access
node binding using the MN-ID but failed to identify the received gateway is able to identify the mobile node binding using the
IPv4 proxy HoA, it MUST send a Binding Revocation Acknowledgement MN-ID but failed to identify the received IPv4 proxy HoA, it MUST
with Status field is set to "Binding Does NOT Exist". send a Binding Revocation Acknowledgement with Status field is set
to "Binding Does NOT Exist".
The Revocation Trigger field value in the received Binding Revocation The Revocation Trigger field value in the received Binding Revocation
Indication could be used by the mobile access gateway to define what Indication could be used by the mobile access gateway to define what
actions the mobile access gateway could do to inform the mobile node actions the mobile access gateway could do to inform the mobile node
that its IP connectivity to the current HNP has been terminated, that its IP connectivity to the current HNP has been terminated,
e.g., if the Revocation Trigger field is set to "Administrative e.g., if the Revocation Trigger field is set to "Administrative
Reason", the mobile access gateway may send a RA message after Reason", the mobile access gateway may send a RA message after
setting the Home Network Prefix valid lifetime to zero. setting the Home Network Prefix valid lifetime to zero.
10.1.2. Sending Binding Revocation Acknowledgement 9.1.2. Sending Binding Revocation Acknowledgement
When the mobile access gateway receives a valid Binding Revocation When the mobile access gateway receives a valid Binding Revocation
Indication with the Acknowledge (A) bit set and after processing it, Indication with the Acknowledge (A) bit set and after processing it,
the mobile access gateway sends a packet to the local mobility anchor the mobile access gateway MUST send a packet to the local mobility
containing a Binding Revocation Acknowledgement according to the anchor containing a Binding Revocation Acknowledgement according to
procedure in Section 7.1 and the following: the procedure in Section 6.1 and the following:
o The mobile access gateway MUST set the (P) bit in the Binding o The mobile access gateway MUST set the (P) bit in the Binding
Revocation Acknowledgement if it is set in the received Binding Revocation Acknowledgement if it is set in the received Binding
Revocation Indication. Revocation Indication.
o If the Global (G) bit was set in the received Binding Revocation o If the Global (G) bit was set in the received Binding Revocation
Indication, the mobile access gateway MUST set the Global (G) bit Indication, the mobile access gateway MUST set the Global (G) bit
in the Binding Revocation Acknowledgement. in the Binding Revocation Acknowledgement.
o If the IPv4 HoA Binding Only (V) bit was set in the received o If the IPv4 HoA Binding Only (V) bit was set in the received
skipping to change at page 34, line 5 skipping to change at page 35, line 9
released before receiving the Binding Revocation Indication, the released before receiving the Binding Revocation Indication, the
mobile access gateway MAY set the Status field to "partial mobile access gateway MAY set the Status field to "partial
success" and include the mobile node identifier, MN-ID, or the success" and include the mobile node identifier, MN-ID, or the
Home Network Prefix option to identify the binding(s) that failed Home Network Prefix option to identify the binding(s) that failed
to be removed as part of the revocation procedure. to be removed as part of the revocation procedure.
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 9.2. Binding Revocation Initiator
10.2.1. Sending Binding Revocation Indication 9.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 set. e.g., when using the global revocation with the Global (G) bit set.
In this case when an event occurs which requires the mobile access In this case when an event occurs which requires the mobile access
gateway to inform the local mobility anchor to terminate all mobile gateway to inform the local mobility anchor to terminate all mobile
nodes bindings which are registered at the local mobility anchor and nodes bindings which are registered at the local mobility anchor and
the mobile access gateway, the mobile access gateway sends a Binding the mobile access gateway, the mobile access gateway sends a Binding
Revocation Indication message following Section 7.1 and the Revocation Indication message following Section 6.1 and the
following: following:
o The Acknowledge (A) bit MUST be set to request the local mobility o The Acknowledge (A) bit MUST be set to request the local mobility
anchor to send a Binding Revocation Acknowledgement upon receipt anchor to send a Binding Revocation Acknowledgement upon receipt
of the Binding Revocation Indication. of the Binding Revocation Indication.
o The Proxy Binding (P) bit MUST be set to indicate that bindings o The Proxy Binding (P) bit MUST be set to indicate that bindings
that being revoked is a PMIPv6 binding. that being revoked is a PMIPv6 binding.
o The Global (G) bit MUST be set and the Revocation Trigger MUST o The Global (G) bit MUST be set and the Revocation Trigger MUST
contain a value of "Per-Peer Policy" in the Binding Revocation contain a value of "Per-Peer Policy" in the Binding Revocation
Indication to request the local mobility anchor to remove all Per- Indication to request the local mobility anchor to remove all Per-
Peer bindings that are registered with the local mobility anchor Peer bindings that are registered with the local mobility anchor
and hosted at this mobile access gateway. In this case, the MN-ID and this mobile access gateway. In this case, the MN-ID option
option MUST be included in the Binding Revocation Indication and MUST be included in the Binding Revocation Indication and contain
contain the mobile access gateway identity. In addition, the the mobile access gateway identity. In addition, the mobile
mobile access gateway MAY include one or more Alternate Care-of access gateway MAY include one or more Alternate Care-of Address
Address option(s). The Alternate Care-of Address option(s) option(s). The Alternate Care-of Address option(s) contain the
contain the proxy Care-of address(es) the bindings of which are proxy Care-of address(es) the bindings of which are being impacted
being impacted by this Binding Revocation Indication message. by this Binding Revocation Indication message.
o The mobile access gateway address MAY be used as the source o The mobile access gateway address MAY be used as the source
address in the packet's IPv6 header. address in the packet's IPv6 header.
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the local mobility anchor to return a Binding Revocation the local mobility anchor to return a Binding Revocation
Acknowledgement in response to this Binding Revocation Indication. Acknowledgement in response to this Binding Revocation Indication.
As described in Section 7.3, the mobile access gateway SHOULD As described in Section 6.3, the mobile access gateway SHOULD
retransmit this Binding Revocation Indication to the local mobility retransmit this Binding Revocation Indication to the local mobility
anchor until it receives a matching Binding Revocation anchor until it receives a matching Binding Revocation
Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile
access gateway MAY delete the mobile nodes IP tunnels immediately access gateway MAY delete the mobile nodes IP tunnels immediately
after sending the Binding Revocation Indication and before receiving after sending the Binding Revocation Indication and before receiving
a Binding Revocation Acknowledgement message from the LMA. a Binding Revocation Acknowledgement message from the LMA.
10.2.2. Receiving Binding Revocation Acknowledgement 9.2.2. Receiving Binding Revocation Acknowledgement
When the mobile access gateway receives a packet carrying a valid When the mobile access gateway receives a packet carrying a valid
Binding Revocation Acknowledgement that was successfully processed Binding Revocation Acknowledgement that was successfully processed
according to Section 7.2, the mobile access gateway MUST process the according to Section 6.2, the mobile access gateway MUST process the
received Binding Revocation Acknowledgement as per the followings: received Binding Revocation Acknowledgement as per the followings:
o When the mobile access gateway receives a packet carrying a valid o When the mobile access gateway receives a packet carrying a valid
Binding Revocation Acknowledgement and the Global (G) and Proxy Binding Revocation Acknowledgement and the Global (G) and Proxy
Binding (P) bits are set and the mobile nodes BCEs are in the Binding (P) bits are set and the mobile nodes BCEs are in the
state of Revocation in Progress, the mobile access gateway SHOULD state of Revocation in Progress, the mobile access gateway 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 mobile access gateway Indication was processed successfully, the mobile access gateway
MUST delete the current timer and the mobile nodes proxy bindings MUST delete the current timer and the mobile nodes proxy bindings
and all associated resources. and all associated resources.
o If the Status field indicates (Global Revocation NOT Authorized), o If the Status field indicates (Global Revocation NOT Authorized),
the mobile access gateway is not authorized to participate in a the mobile access gateway is not authorized to participate in a
Per-Peer Global Revocation. The mobile access gateway SHOULD NOT Per-Peer Global Revocation. The mobile access gateway SHOULD NOT
retry sending a Binding Revocation Indication with the Global (G) retry sending a Binding Revocation Indication with the Global (G)
bit set to the same local mobility agent. The mobile access bit set and the Revocation Trigger field value is set to "Per-Peer
Policy" to the same local mobility agent. The mobile access
gateway should raise an alarm or log an event to indicate this gateway should raise an alarm or log an event to indicate this
rejection. rejection.
11. Mobile Node Operation 10. Mobile Node Operation
11.1. Receiving Binding Revocation Indication 10.1. Receiving Binding Revocation Indication
Upon receiving a packet carrying a Binding Revocation Indication, the Upon receiving a packet carrying a Binding Revocation Indication, the
mobile node MUST validate the packet according to Section 7.2 and the mobile node MUST validate the packet according to Section 6.2 and the
following tests: following tests:
o The mobile node MUST verify that the IP address in the Type 2 o The mobile node MUST verify that the IP address in the Type 2
routing header is its Home Address and that its Binding Update routing header is its Home Address and that its Binding Update
List contains an entry for that Home Address. If one of the List contains an entry for that Home Address. If one of the
tests, fails the mobile node SHOULD silently discard the received tests, fails the mobile node SHOULD silently discard the received
Binding Revocation Indication message. Binding Revocation Indication message.
o If the Acknowledge (A) bit is set in the Binding Revocation o If the Acknowledge (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 Acknowledge (A) bit is set in the BRI, the mobile node when the Acknowledge (A) bit is set in the BRI, the mobile node
SHOULD send a Binding Revocation Acknowledgement. In all cases, SHOULD sends a Binding Revocation Acknowledgement, the mobile node
the mobile node MUST follow Section 11.2 and send a Binding MUST do so according to Section 10.2.
Revocation Acknowledgement using the appropriate 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 mobile node MUST verify that there is an IPv4 Home message, the mobile node MUST verify that there is an IPv4 Home
Address option in the received Binding Revocation Indication and Address option in the received Binding Revocation Indication and
the IPv4 address included in the IPv4 Home Address option is the the IPv4 address included in the IPv4 Home Address option is the
same as its IPv4 HoA that is assigned to the mobile node. If this same as its IPv4 HoA that is assigned to the mobile node. If this
verification is successful, the mobile node MUST consider this verification is successful, the mobile node MUST consider this
Binding Revocation Indication as an indication to release the Binding Revocation Indication as an indication to ONLY release the
mobile node IPv4 HoA binding ONLY to its current Care-of Address. mobile node IPv4 HoA binding to its current Care-of Address.
Consequently, the mobile node MUST continue to maintain its IPv6 Consequently, the mobile node MUST continue to maintain its IPv6
HoA binding to the current CoA as part of the mobile node binding HoA binding to the current CoA as part of the mobile node binding
in the BUL entry and release all resources associated with the MN in the BUL entry and release all resources associated with the MN
IPv4 HoA binding. In this case, the mobile node MUST send a IPv4 HoA binding. In this case, if the Acknowledge (A) bit is
Binding Revocation Acknowledgement message with the Status field set, the mobile node MUST send a Binding Revocation
is set to "success". On the other hand, if the IPv4 Home Address Acknowledgement message with the Status field is set to "success".
Option was NOT included in the received BRI with the (V) bit set, On the other hand, if the IPv4 Home Address Option was NOT
the MN SHOULD send a Binding Revocation Acknowledgement message included in the received BRI with the (V) bit set and the
with the Status field set to "IPv4 Home Address Option Required". Acknowledge (A) bit is set, the MN SHOULD send a Binding
Additionally, if the IPv4 HoA received in the IPv4 Home Address Revocation Acknowledgement message with the Status field set to
Option is NOT the one assigned to the mobile node, the mobile node "IPv4 Home Address Option Required". Additionally, if the IPv4
SHOULD send a Binding Revocation Acknowledgement with the status HoA received in the IPv4 Home Address Option is NOT the one
field set to "Binding Does NOT Exist". assigned to the mobile node, the mobile node SHOULD send a Binding
Revocation Acknowledgement with the status field set to "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 Binding Revocation revoked by examining the content of the Binding Revocation
Indication message. If the mobile node received a Binding Indication message. If the mobile node received a Binding
Revocation Indication with a single or more than one BID options Revocation Indication with a single or more than one BID options
and its home address is included in the Type 2 routing header, the and its home address is included in the Type 2 routing header, the
mobile node MUST consider all of the care-of address(es) mobile node MUST consider all of the care-of address(es)
binding(s), identified in the BID options, with this home address binding(s), identified in the BID options, with this home address
are being revoked. as being revoked.
o If the mobile node has multi Care-of Address bindings with its o If the mobile node has multiple Care-of Address bindings with its
home agent and received a Binding Revocation Indication, without home agent and received a Binding Revocation Indication, without
any BID option included and its home address was included in the any BID option included and its home address was included in the
Type 2 routing header, the mobile node MUST consider all of its Type 2 routing header, the mobile node MUST consider all of its
registered care-of addresses bindings with this home address are registered care-of addresses bindings with this home address as
being revoked. being revoked.
The Revocation Trigger field value in the received Binding Revocation The Revocation Trigger field value in the received Binding Revocation
Indication could be used by the mobile node to define what action the Indication could be used by the mobile node to define what action the
mobile node could do to be able to register again and receive its IP mobile node could do to be able to register again and receive its IP
mobility service, e.g., contacting its home operator. mobility service, e.g., contacting its home operator.
11.2. Sending Binding Revocation Acknowledgement 10.2. Sending Binding Revocation Acknowledgement
When the mobile node receives a Binding Revocation Indication from When the mobile node receives a Binding Revocation Indication from
its home agent, the mobile node processes the received Binding its home agent, the mobile node processes the received Binding
Revocation Indication as in Section 11.1. If the mobile node is Revocation Indication as in Section 10.1. If the mobile node is
required to send a Binding Revocation Acknowledgement message in required to send a Binding Revocation Acknowledgement message in
response to the received Binding Revocation Indication, the mobile response to the received Binding Revocation Indication, the mobile
node sends a packet to its home agent containing a Binding Revocation node sends a packet to its home agent containing a Binding Revocation
Acknowledgement according to the procedure in Section 7.1 and the Acknowledgement according to the procedure in Section 6.1 and the
following: following:
o The mobile node MUST set the Status field to an appropriate value. o The mobile node MUST set the Status field to an appropriate value.
The mobile node sets the Status field to success to reflect that The mobile node sets the Status field to success to reflect that
it has received the Binding Revocation Indication and acknowledge it has received the Binding Revocation Indication and acknowledge
that its IP connectivity with its home agent has been revoked. that its IP connectivity with its home agent has been revoked.
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 IPv6 packet of the Binding Revocation Indication. The received IPv6 packet of the Binding Revocation Indication. The
Mobile Node MUST include its home address in the Home Address Mobile Node MUST include its home address in the Home Address
Destination Option. Destination Option.
12. Protocol Configuration Variables 11. Protocol Configuration Variables
Any mobility entity which is allowed to invoke the binding revocation Any mobility entity which is allowed to invoke the binding revocation
procedure by sending a Binding Revocation Indication message SHOULD procedure by sending a Binding Revocation Indication message SHOULD
allow the following variables to be configured. allow the following variables to be configured.
BRI Maximum Number of Retries (BRIMaxRetriesNumber) BRI Maximum Number of Retries (BRIMaxRetriesNumber)
This variable specifies the maximum Number of times a mobility This variable specifies the maximum Number of times a mobility
entity can retransmit a Binding Revocation Indication message entity can retransmit a Binding Revocation Indication message
before receiving a Binding Revocation Acknowledgement message. before receiving a Binding Revocation Acknowledgement message.
skipping to change at page 38, line 11 skipping to change at page 39, line 17
This variable specifies the initial delay timeout in seconds This variable specifies the initial delay timeout in seconds
before the revoking mobility entity retransmits a BRI message. before the revoking mobility entity retransmits a BRI message.
The default is 1 second but not less than 0.5 seconds. The default is 1 second but not less than 0.5 seconds.
Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT) Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)
This variable specifies the maximum delay timeout in seconds This variable specifies the maximum delay timeout in seconds
before the revoking mobility entity retransmits a BRI message. before the revoking mobility entity retransmits a BRI message.
The default is 2 seconds. The default is 2 seconds.
13. IANA Considerations 12. IANA Considerations
This specification defines a new Binding Revocation Message using a This specification defines a new Binding Revocation Message using a
new Mobility Header Type <IANA-TBD>, as described in Section 6. The new Mobility Header Type <IANA-TBD>, as described in Section 5. The
new Mobility Header type value needs to be assigned from the same new Mobility Header type value needs to be assigned from the same
numbering space as allocated for the other Mobility Header types. numbering space as allocated for the other Mobility Header types
registry.
This document also creates a new name space "Binding Revocation Type" This document also creates a new registry "Binding Revocation Type"
which indicates the type of the binding revocation message. The which indicates the type of the binding revocation message. The
current binding revocation message types are described in Section 6.1 current binding revocation message types are described in Section 5.1
and Section 6.2, and are the following: and Section 5.2, and are the following:
0 Reserved 0 Reserved
1 Binding Revocation Indication 1 Binding Revocation Indication
2 Binding Revocation Acknowledgement 2 Binding Revocation Acknowledgement
All other values are reserved All other values are reserved
Future values of the Binding Revocation Type can be allocated using Future values of the Binding Revocation Type can be allocated using
Standards Action or IESG Approval [RFC5226]. Standards Action or IESG Approval [RFC5226].
In addition, this document also creates a second new namespace for In addition, this document also creates a second new registry for the
the Revocation Trigger which indicates the reason behind sending the Revocation Trigger which indicates the reason behind sending the
Binding Revocation Indication message. The current Revocation Binding Revocation Indication message. The current Revocation
Trigger values are described in Section 6.1, and are the following: Trigger values are described in Section 5.1, and are the following:
Reserved and Per-MN Revocation Trigger Values: Reserved and Per-MN Revocation Trigger Values:
0 Reserved 0 Reserved
1 Unspecified 1 Unspecified
2 Administrative Reason 2 Administrative Reason
3 Inter-MAG Handover - same Access Type 3 Inter-MAG Handover - same Access Type
4 Inter-MAG Handover - different Access Type 4 Inter-MAG Handover - different Access Type
5 Inter-MAG Handover - Unknown 5 Inter-MAG Handover - Unknown
6 User Initiated Session(s) Termination 6 User Initiated Session(s) Termination
7 Access Network Session(s) Termination 7 Access Network Session(s) Termination
skipping to change at page 39, line 13 skipping to change at page 40, line 20
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 Values: Global Revocation Trigger Values:
128 Per-Peer Policy 128 Per-Peer Policy
129 Revoking Mobility Node Local Policy 129 Revoking Mobility Node Local Policy
Future values of the Revocation Trigger can be allocated using Future values of the Revocation Trigger can be allocated using
Standards Action or IESG Approval [RFC5226]. Standards Action or IESG Approval [RFC5226].
Furthermore, this document creates a third new name space "Status Furthermore, this document creates a third new registry "Status Code"
Code" for the Status field in the Binding Revocation Acknowledgement for the Status field in the Binding Revocation Acknowledgement
message. The current values are described in Section 6.2, and are message. The current values are described in Section 5.2, and are
the following: the following:
0 success 0 success
1 partial success 1 partial success
128 Binding Does NOT Exist 128 Binding Does NOT Exist
129 IPv4 Home Address Option Required 129 IPv4 Home Address Option Required
130 Global Revocation NOT Authorized 130 Global Revocation NOT Authorized
131 Revoked Mobile Nodes Identity Required 131 Revoked Mobile Nodes Identity Required
132 Revocation Failed - MN is Attached 132 Revocation Failed - MN is Attached
133 Revocation Trigger NOT Supported 133 Revocation Trigger NOT Supported
134 Revocation Function NOT Supported 134 Revocation Function NOT Supported
Future values of the Status field can be allocated using Standards Future values of the Status field can be allocated using Standards
Action or IESG Approval [RFC5226]. Action or IESG Approval [RFC5226].
All fields labeled "Reserved" are only to be assigned through All fields labeled "Reserved" are only to be assigned through
Standards Action or IESG Approval. Standards Action or IESG Approval.
14. Security Considerations 13. Security Considerations
The protocol described here uses the same security association This specification allows the mobility node which initiates the
between the mobile node and the home agent or the mobile access binding revocation procedure to revoke mobility session(s) that is
gateway and the local mobility anchor that has been used to exchange currently registered with it. It is NOT allowed for any mobility
the corresponding MIPv6 or PMIPv6 Binding Update and Binding node to revoke a mobile node mobility session that is not registered
Acknowledgement when the session was established. If IPsec is used, with this mobility node.
the SPD of this IPsec SA MUST allow the MH type for the Binding
Revocation Message defined in this document.
However, in the case when the mobile access gateway sends a Binding The binding revocation protocol described in this specification uses
Revocation Indication message with the Global (G) bit is set and the the same security association between the mobile node and the home
Revocation Trigger field is set to "Per-Peer policy", the local agent or the mobile access gateway and the local mobility anchor that
mobility anchor MUST verify that the mobile access gateway is is being used to exchange the MIPv6 or PMIPv6 Binding Update and
authorized to use Per-Peer Global Revocation. Binding Acknowledgement signaling. If IPsec is used, the traffic
selectors associated with the SPD entry protecting the Binding Update
and Binding Acknowledgement MUST be extended to include Binding
Revocation Message MH type <IANA-TBD>. Extending the traffic
selectors of the SPD entry in order to reuse the SA protecting the
Binding Update and Binding Acknowledgement (instead of creating new
ones) ensures that those SA will be up and running when the revoking
entity needs to send a binding revocation signaling message.
15. Acknowledgements On the other hand, if IPsec is not used as the underlying security
mechanism to protect the Mobile IPv6 and its extensions binding
registration signaling, the used underlying security mechanism MUST
provide protection against all identified security threats as
described under Security Considerations in [RFC3775] and [RFC5213].
The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to
restrict the creation and manipulation of proxy bindings to
specifically authorized mobile access gateways. Therefore, the
mobile access gateway which is authorized to create or manipulate the
mobile node proxy BCE is also authorized to revoke such mobile node
registration by sending a de-registration with lifetime of zero.
However, since bulk termination using Binding Revocation Indication
with the Global (G) bit set and the Revocation Trigger field set to
"Per-Peer Policy" impact all mobility sessions that are registered
with the mobile access gateway and its local mobility anchor peer,
the local mobility anchor MUST be locally configurable to authorize
such specific functionality. Additional mechanisms, such as a policy
store or Authentication, Authorization, and Accounting (AAA) may be
employed, but these are outside the scope of this specification.
14. 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, Patrick Stupar, Vijay Cazavet, Domagoj Premec, Arnaud Ebalard, Patrick Stupar, Vijay
Devarapalli, and Joel Hortelius for their review and comments of this Devarapalli, and Joel Hortelius for their review and comments of this
draft and all colleagues who have supported the advancement of this draft and all colleagues who have supported the advancement of this
draft effort. draft effort.
16. References 15. References
16.1. Normative References 15.1. Normative References
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[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.
[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-14 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-15
(work in progress), July 2009. (work in progress), August 2009.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration", "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-14 (work in progress), draft-ietf-monami6-multiplecoa-14 (work in progress),
May 2009. May 2009.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
16.2. Informative References 15.2. Informative References
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003. Mobile IPv4", RFC 3543, August 2003.
Authors' Addresses Authors' Addresses
Ahmad Muhanna Ahmad Muhanna
 End of changes. 146 change blocks. 
419 lines changed or deleted 505 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/