draft-ietf-mext-binding-revocation-14.txt   rfc5846.txt 
Network Working Group A. Muhanna Internet Engineering Task Force (IETF) A. Muhanna
Internet-Draft M. Khalil Request for Comments: 5846 M. Khalil
Intended status: Standards Track Nortel Category: Standards Track Ericsson
Expires: April 29, 2010 S. Gundavelli ISSN: 2070-1721 S. Gundavelli
Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Cisco
P. Yegani P. Yegani
Juniper Networks Juniper Networks
October 26, 2009 June 2010
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-14.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the Abstract
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering This document defines a binding revocation mechanism to terminate a
Task Force (IETF), its areas, and its working groups. Note that mobile node's mobility session and the associated resources. This
other groups may also distribute working documents as Internet- mechanism can be used both with base Mobile IPv6 and its extensions,
Drafts. such as Proxy Mobile IPv6. The mechanism allows the mobility entity
which initiates the revocation procedure to request its peer to
terminate either one, multiple or all specified Binding Cache
entries.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 29, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5846.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document defines a binding revocation mechanism to terminate a This document may contain material from IETF Documents or IETF
mobile node's mobility session and the associated resources. These Contributions published or made publicly available before November
semantics are generic enough and can be used by mobility entities in 10, 2008. The person(s) controlling the copyright in some of this
the case of Mobile IPv6 and its extensions. This mechanism allows material may not have granted the IETF Trust the right to allow
the mobility entity which initiates the revocation procedure to modifications of such material outside the IETF Standards Process.
request its peer to terminate either one, multiple or all specified Without obtaining an adequate license from the person(s) controlling
binding(s). the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions used in this document . . . . . . . . . . . . 4 2.1. Conventions Used in This Document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5
3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5
3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6
3.3. Multiple Care-of Addresses (Monami6) Use Case . . . . . . 7 3.3. Multiple Care-of Addresses (MCoA) Use Case . . . . . . . . 7
3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8
3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation . . 9 3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation . . 9
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10
4. Binding Revocation Messages over IPv4 Transport Network . . . 11 4. Binding Revocation Messages over IPv4 Transport Network . . . 10
5. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11 5. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11
5.1. Binding Revocation Indication Message . . . . . . . . . . 13 5.1. Binding Revocation Indication Message . . . . . . . . . . 13
5.2. Binding Revocation Acknowledgement Message . . . . . . . . 16 5.2. Binding Revocation Acknowledgement Message . . . . . . . . 16
6. Binding Revocation Process Operation . . . . . . . . . . . . . 18 6. Binding Revocation Process Operation . . . . . . . . . . . . . 18
6.1. Sending Binding Revocation Message . . . . . . . . . . . . 18 6.1. Sending Binding Revocation Message . . . . . . . . . . . . 18
6.1.1. Sending Binding Revocation Indication . . . . . . . . 19 6.1.1. Sending Binding Revocation Indication . . . . . . . . 18
6.1.2. Sending Binding Revocation Acknowledgement . . . . . . 19 6.1.2. Sending Binding Revocation Acknowledgement . . . . . . 19
6.2. Receiving Binding Revocation Message . . . . . . . . . . . 21 6.2. Receiving Binding Revocation Message . . . . . . . . . . . 20
6.2.1. Receiving Binding Revocation Indication . . . . . . . 21 6.2.1. Receiving Binding Revocation Indication . . . . . . . 20
6.2.2. Receiving Binding Revocation Acknowledgement . . . . . 21 6.2.2. Receiving Binding Revocation Acknowledgement . . . . . 21
6.3. Retransmission of Binding Revocation Indication . . . . . 22 6.3. Retransmission of Binding Revocation Indication . . . . . 22
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24 8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 23
8.1. Sending Binding Revocation Indication . . . . . . . . . . 24 8.1. Sending Binding Revocation Indication . . . . . . . . . . 23
8.2. Receiving Binding Revocation Indication . . . . . . . . . 28 8.2. Receiving Binding Revocation Indication . . . . . . . . . 27
9. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 30 9. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 29
9.1. Receiving Binding Revocation Indication . . . . . . . . . 30 9.1. Receiving Binding Revocation Indication . . . . . . . . . 29
9.2. Sending Binding Revocation Indication . . . . . . . . . . 32 9.2. Sending Binding Revocation Indication . . . . . . . . . . 31
10. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 33 10. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 32
11. Protocol Configuration Variables . . . . . . . . . . . . . . . 34 11. Protocol Configuration Variables . . . . . . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1. Normative References . . . . . . . . . . . . . . . . . . . 38 15.1. Normative References . . . . . . . . . . . . . . . . . . . 37
15.2. Informative References . . . . . . . . . . . . . . . . . . 38 15.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
In the case of Mobile IPv6 and for administrative reason, sometimes In the case of Mobile IPv6 and for administrative reasons, 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 for its Home Address. A similar Mobile IPv4
registration revocation mechanism [RFC3543] has been specified by registration revocation mechanism [RFC3543] has been specified by the
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 Mobility [RFC5213]. The proposed revocation mechanism uses a new Mobility
Header (MH) type <IANA-TBD> for revocation signaling which is Header (MH) type 16 for revocation signaling that is applicable to
applicable to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used
and can be used by any two IP mobility entities. As an example, this by any two IP mobility entities. As an example, this mechanism
mechanism allows a local mobility anchor (LMA), involved in providing allows a local mobility anchor (LMA), involved in providing IP
IP mobility services to a mobile node, to notify the mobile access mobility services to a mobile node, to notify the mobile access
gateway (MAG) of the termination of that mobile node binding gateway (MAG) of the termination of that mobile node binding
registration. In another example, a mobile access gateway can use registration. In another example, a mobile access gateway can use
this mechanism to notify its local mobility anchor peer with a bulk this mechanism to notify its local mobility anchor peer with a bulk
termination of all or a subset of proxy mobile IPv6 (PMIPv6) bindings termination of all or a subset of proxy mobile IPv6 (PMIPv6) bindings
that are registered with the local mobility anchor and currently that are registered with the local mobility anchor and currently
being served by the mobile access gateway. Any mobility entity is being served by the mobile access gateway. Any mobility entity is
allowed to revoke only the registration of those mobile node(s) allowed to revoke only the registration of those mobile node(s)
mobility sessions that are currently registered with it. mobility sessions that are currently registered with it.
2. Conventions & Terminology 2. Conventions and Terminology
2.1. Conventions used in this document 2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Terminology 2.2. Terminology
All the general mobility related terminology and abbreviations are to All the general mobility related terminology and abbreviations are to
be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile be interpreted as defined in the Mobile IPv6 [RFC3775], Proxy Mobile
IPv6 [RFC5213] specifications. The following terms are used in this IPv6 [RFC5213] and IPv4 Support for Proxy Mobile IPv6 [RFC5844]
specification. specifications. The following terms are used in this specification.
Initiator Initiator
The mobility node that initiates the binding revocation procedure The mobility node that initiates the binding revocation procedure
by sending a Binding Revocation Indication message to its peer, by sending a Binding Revocation Indication message to its peer,
e.g., home agent, local mobility anchor, or mobile access gateway. e.g., home agent, local mobility anchor, or mobile access gateway.
Responder Responder
The mobility node that receives the Binding Revocation Indication The mobility node that receives the Binding Revocation Indication
message and responds with a Binding Revocation Acknowledgement message and responds with a Binding Revocation Acknowledgement
message. e.g., mobile node, mobile access gateway, or local message, e.g., mobile node, mobile access gateway, or local
mobility anchor. mobility anchor.
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 mobile node registration binding
binding that is being terminated. In the case when this mechanism is that is being terminated. In the case when this mechanism is used
used for bulk termination or multiple bindings, the identities of for bulk termination or multiple bindings, the identities of these
these bindings are communicated to the mobile node or mobility node bindings are communicated to the mobile node or mobility node using
using the same generic mechanism. The following subsections present the same generic mechanism. The following subsections present the
the protocol overview and applicable use cases. 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)
[RFC5555], the home agent may include the IPv4 Home Address option [RFC5555], the home agent may include the IPv4 Home Address option
with the mobile node assigned home IPv4 address. Additionally, if with the home IPv4 address assigned by the mobile node.
the mobile node registered multiple care-of addresses [RFC5648], the Additionally, if the mobile node registered multiple care-of
home agent includes the Binding Identifier (BID) option(s) in the addresses [RFC5648], the home agent includes the Binding Identifier
Binding Revocation Indication message to identify which binding is (BID) option(s) in the Binding Revocation Indication message to
being revoked. When the mobile node receives a Binding Revocation identify which binding is being revoked. When the mobile node
Indication message with its HoA included in the Type 2 routing receives a Binding Revocation Indication message with its HoA
header, the mobile node responds by sending a Binding Revocation included in the Type 2 routing header, the mobile node responds by
Acknowledgement (BRA) message. sending a Binding Revocation Acknowledgement (BRA) message.
Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation
procedure can be initiated by the local mobility anchor by sending a procedure can be initiated by the local mobility anchor by sending a
Binding Revocation Indication message to communicate the termination Binding Revocation Indication message to communicate the termination
of a mobile node registration binding to the mobile access gateway. of a mobile node registration binding to the mobile access gateway.
In this case, the local mobility anchor includes the mobile node Home In this case, the local mobility anchor includes the mobile node Home
Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option
[RFC4283] to indicate to the mobility access gateway the identity of [RFC4283] to indicate to the mobility access gateway the identity of
the PMIPv6 binding that needs to be terminated. When the mobile the PMIPv6 binding that needs to be terminated. When the mobile
access gateway receives the Binding Revocation Indication message, access gateway receives the Binding Revocation Indication message,
the mobile access gateway responds to the local mobility anchor by the mobile access gateway responds to the local mobility anchor by
sending a Binding Revocation Acknowledgement message. sending a Binding Revocation Acknowledgement message.
On the other hand, the mobile access gateway usually sends a de- On the other hand, the mobile access gateway usually sends a de-
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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
the PMIPv6 binding that needs to be terminated. When the mobile the PMIPv6 binding that needs to be terminated. When the mobile
access gateway receives the Binding Revocation Indication message, access gateway receives the Binding Revocation Indication message,
the mobile access gateway responds to the local mobility anchor by the mobile access gateway responds to the local mobility anchor by
sending a Binding Revocation Acknowledgement message. sending a Binding Revocation Acknowledgement message.
On the other hand, the mobile access gateway usually sends a de- On the other hand, the mobile access gateway usually sends a de-
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) bit is set and includes the mobile access message with the Global (G) bit set and includes the mobile access
gateway identity in the MN-ID option, see Section 9.2 and gateway identity in the MN-ID option, see Section 9.2 and
Section 8.2. When the local mobility anchor receives such Binding Section 8.2. When the local mobility anchor receives such a Binding
Revocation Indication message, it ensures that the mobile access Revocation Indication message, it ensures that the mobile access
gateway is authorized to send such bulk termination message, see gateway is authorized to send such a bulk termination message, see
Section 13, and then processes the Binding Revocation Indication Section 13, and then processes the Binding Revocation Indication
message accordingly. If the local mobility anchor processes the message accordingly. If the local mobility anchor processes the
Binding Revocation Indication message successfully, the local Binding Revocation Indication message successfully, the local
mobility anchor responds to the mobile access gateway by sending mobility anchor responds to the mobile access gateway by sending
Binding Revocation Acknowledgement message. 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, or 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
The binding revocation mechanism is applicable to Mobile IPv6 and The binding revocation mechanism is applicable to Mobile IPv6 and
DSMIPv6 session(s) when the home agent needs to inform the mobile DSMIPv6 session(s) when the home agent needs to inform the mobile
node that its binding registration has been revoked, e.g. for an node that its binding registration has been revoked, e.g., for an
administrative reason. This mechanism enables the user or the mobile administrative reason. This mechanism enables the user or the mobile
node to react to the revocation, e.g., reinstate its interrupted node to react to the revocation, e.g., reinstate its interrupted
Mobile IPv6 services. 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 is no longer able to receive (MIPv6) binding has been revoked and it is no longer able to receive
IP mobility service. The home agent includes the HoA in Type 2 IP mobility service. The home agent includes the HoA in a Type 2
routing header as used in [RFC3775] and sets the Revocation Trigger routing header as used in [RFC3775] and sets the Revocation Trigger
field to a proper value, e.g., Administrative Reason. In the case of field to a proper value, e.g., Administrative Reason. In the case of
DSMIPv6 session, the home agent may additionally include the mobile a DSMIPv6 session, the home agent may additionally include the
node assigned IPv4 Home Address in the IPv4 Home Address option. mobile-node-assigned IPv4 Home Address in the IPv4 Home Address
When the mobile node receives the Binding Revocation Indication option. When the mobile node receives the Binding Revocation
message, it sends a Binding Revocation Acknowledgement message to the Indication message, it sends a Binding Revocation Acknowledgement
home agent. Figure 1 illustrates the message sequencing when home message to the home agent. Figure 1 illustrates the message
agent revokes a mobile node binding registration. sequencing when a home agent revokes a mobile node binding
registration.
MN HA MN HA
| | | |
| HoA in Type 2 Hdr | | HoA in Type 2 Routing Hdr |
|<<<------------... + ...-----------------| |<<<------------... + ...-----------------|
| BRI [seq.#, Revocation Trigger] | | BRI [seq.#, 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. Multiple Care-of Addresses (Monami6) Use Case 3.3. Multiple Care-of Addresses (MCoA) Use Case
In the case of multiple care-of addresses registration [RFC5648], the In the case of multiple care-of address registrations [RFC5648], the
home agent maintains different binding for each pair of care-of home agent maintains a different binding for each care-of address and
address and home address. These bindings are also indexed and home address pair. These bindings are also indexed and identified
identified during the mobile node registration using a BID mobility during the mobile node registration using a BID mobility option. The
option. The HA may revoke one or multiple bindings for the same HA may revoke one or multiple bindings for the same mobile node home
mobile node home address. 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 address registrations, the home agent sends a
Binding Revocation Indication message to the mobile node with the Binding Revocation Indication message to the mobile node with the
corresponding BID option included. If more than one of the mobile corresponding BID option included. If more than one of the mobile
node registered care-of addresses need to be revoked, the home agent node registered care-of addresses needs to be revoked, the home agent
includes all the corresponding BID options in the same Binding includes all the corresponding BID options in the same Binding
Revocation Indication message. Figure 2 illustrates the message flow Revocation Indication message. Figure 2 illustrates the message flow
when the home agent revokes two registered Care-of addresses for the when the home agent revokes two registered care-of addresses for the
same mobile node in a single Binding Revocation Indication message. same mobile node in a single Binding Revocation Indication message.
HA Binding Cache HA Binding Cache
================ ================
MN-BID1 [CoA1+HoA] MN-BID1 [CoA1+HoA]
MN HA MN-BID2 [CoA2+HoA] MN HA MN-BID2 [CoA2+HoA]
| | MN-BID3 [CoA3+HoA] | | MN-BID3 [CoA3+HoA]
| | MN-BID4 [CoA4+HoA] | | MN-BID4 [CoA4+HoA]
| HoA in Type 2 Hdr | | HoA in Type 2 Routing Hdr |
|<<<<-------------- + ---------------------| |<<<<-------------- + ---------------------|
| BRI [seq.#, R. Trigger, BID1, BID4] | | BRI [seq.#, R. Trigger, BID1, BID4] |
| | | |
| | | |
| BRA (HoA in Dest. Option) [seq.#, Status] | | BRA (HoA in Dest. Option) [seq.#, Status] |
|---------------------------------------->>>>| |---------------------------------------->>>>|
| | | |
| | | |
Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings Figure 2: Home Agent Revokes MN's Specific Care-of Address Bindings
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 address 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 the 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 it can be used for all Proxy Mobile IPv6
that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. scenarios that follow the [RFC5213] and [RFC5844] specifications.
When the mobile access gateway receives a Binding Revocation When the mobile access gateway receives a Binding Revocation
Indication message as in Section 9.1, the mobile access gateway sends Indication message as in Section 9.1, the mobile access gateway sends
a Binding Revocation Acknowledgement message to the local mobility a Binding Revocation Acknowledgement message to the local mobility
anchor following the rules described in Section 6.1.2. Similarly, if anchor following the rules described in Section 6.1.2. Similarly, if
the local mobility anchor receives a Binding Revocation Indication the local mobility anchor receives a Binding Revocation Indication
message, the local mobility anchor responds to the mobile access message, the local mobility anchor responds to the mobile access
gateway by sending a Binding Revocation Acknowledgement message. gateway by sending a Binding Revocation Acknowledgement message.
3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation 3.4.1. Local Mobility Anchor Initiates PMIPv6 Revocation
The local mobility anchor may send a Binding Revocation Indication The local mobility anchor may send a Binding Revocation Indication
message with the appropriate revocation trigger value to the mobile message with the appropriate revocation trigger value to the mobile
access gateway that hosts a specific PMIPv6 binding to indicate that access gateway that hosts a specific PMIPv6 binding to indicate that
the mobile node binding has been terminated and the mobile access the mobile node binding has been terminated and the mobile access
gateway can clean up the applicable resources. When the mobile gateway can clean up the applicable resources. When the mobile
access gateway receives a Binding Revocation Indication message, the access gateway receives a Binding Revocation Indication message, the
mobile access gateway identifies the respected binding and it sends a mobile access gateway identifies the respective binding and it sends
Binding Revocation Acknowledgement message to the local mobility a Binding Revocation Acknowledgement message to the local mobility
anchor. In this case, the mobile access gateway could send a Router anchor. In this case, the mobile access gateway could terminate the
Advertisement message to the mobile node with the home network prefix IPv6 or IPv4 mobility session on the access link and notify the
valid lifetime set to zero. mobile node as in Section 9.1.
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
of-address to the local mobility anchor to update the mobile node's care-of address to the local mobility anchor to update the mobile
point of attachment. Since the mobile node binding at the local node's point of attachment. Since the mobile node binding at the
mobility anchor points to the source MAG and upon receiving the Proxy local mobility anchor points to the source MAG and upon receiving the
Binding Update from the target MAG, the local mobility anchor updates Proxy Binding Update from the target MAG, the local mobility anchor
the MN Binding Cache Entry (BCE) and send a Proxy Binding updates the MN Binding Cache entry (BCE) and sends a Proxy Binding
Acknowledgement to the target MAG. The local mobility anchor can Acknowledgement to the target MAG. The local mobility anchor can
send a Binding Revocation Indication message with the appropriate send a Binding Revocation Indication message with the appropriate
revocation trigger value, e.g. inter-MAG handover - different Access revocation trigger value, e.g., inter-MAG handover - different Access
Types, to the source MAG in order to clean up the applicable Types, to the source MAG in order to clean up the applicable
resources reserved for the specified mobile node binding. The source resources reserved for the specified mobile node binding. The source
mobile access gateway acknowledges the Binding Revocation Indication mobile access gateway acknowledges the Binding Revocation Indication
message by sending a Binding Revocation Acknowledgement message to message by sending a Binding Revocation Acknowledgement message to
indicate the success or failure of the termination of the mobile indicate the success or failure of the termination of the mobile
node's binding. 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
skipping to change at page 10, line 27 skipping to change at page 10, line 27
|<-----------------------------------------| |<-----------------------------------------|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| BRA [seq.#, Status, P bit] | | BRA [seq.#, Status, P bit] |
|----------------------------------------->| |----------------------------------------->|
| | | | | |
| | | | | |
Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover Figure 3: LMA Revokes an 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 that 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 8.1. in Section 8.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
set and the Revocation Trigger field set to "Per-Peer Policy" to set and the Revocation Trigger field set to "Per-Peer Policy" to
indicate that all mobility bindings which are registered at the local indicate that all mobility bindings that are registered at the local
mobility anchor and attached to the mobile access gateway are being mobility anchor and attached to the mobile access gateway are being
revoked as in Section 9.2. When the local mobility anchor receives revoked as in Section 9.2. When the local mobility anchor receives
this Binding Revocation Indication message from the specified mobile this Binding Revocation Indication message from the specified mobile
access gateway, the local mobility anchor first checks if the mobile access gateway, the local mobility anchor first checks if the mobile
access gateway is authorized to use global revocations, then it access gateway is authorized to use global revocations, then it
responds with the appropriate status code by sending a Binding responds with the appropriate status code by sending a Binding
Revocation Acknowledgement message as in Section 6.1.2. Revocation Acknowledgement message as in Section 6.1.2.
4. 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 that 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 [ID-PMIP6-IPv4] and [RFC5555] to are sent using UDP encapsulation [RFC5844] [RFC5555], then the
traverse NATs, then the Binding Revocation messages are sent using Binding Revocation Messages are sent using the same UDP
the same UDP encapsulation. The same UDP source and destination port encapsulation. The same UDP source and destination port numbers and
numbers and IPv4 addresses used for exchanging the Proxy Binding IPv4 addresses used for exchanging the Proxy Binding Update and Proxy
Update and Proxy Binding Acknowledgement or the Binding Update and Binding Acknowledgement or the Binding Update and Binding
Binding Acknowledgement messages MUST be used when transporting Acknowledgement messages MUST be used when transporting Binding
Binding Revocation messages over IPv4 using UDP encapsulation. For Revocation Messages over IPv4 using UDP encapsulation. For example,
example, the source UDP port number, the destination UDP port number, the source UDP port number, the destination UDP port number, the
the source IPv4 address, and the destination IPv4 address of the source IPv4 address, and the destination IPv4 address of the Binding
Binding Revocation Indication message are set to the destination UDP Revocation Indication message are set to the destination UDP port
port number, the source UDP port number, destination IPv4 address, number, the source UDP port number, destination IPv4 address, and
and source IPv4 address of the latest received and successfully source IPv4 address of the latest received and successfully processed
processed Proxy Binding Update or Binding Update message, Proxy Binding Update or Binding Update message, respectively. For
respectively. For more details on tunneling Proxy Mobile IPv6 and more details on tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling
Mobile IPv6 signaling messages over IPv4, see [ID-PMIP6-IPv4] and messages over IPv4, see [RFC5844] and [RFC5555], respectively.
[RFC5555], respectively.
5. 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 an
Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding MH Type 16 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 5.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 5.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 Payload Proto
8-bit selector. see [RFC3775] for more details. 8-bit selector. See [RFC3775] for more details.
Header Len Header Len
8-bit unsigned integer. representing the length of the Mobility 8-bit unsigned integer. Representing the length of the Mobility
Header in units of 8 octets, excluding the first 8 octets. see Header in units of 8 octets, excluding the first 8 octets. See
[RFC3775] for more details. [RFC3775] for more details.
MH Type MH Type
<IANA-TBD> which identifies the mobility message as a Binding 16, which identifies the mobility message as a Binding Revocation
Revocation message. 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.
Checksum Checksum
16-bit unsigned integer. This field contains the checksum of the 16-bit unsigned integer. This field contains the checksum of the
Mobility Header. The checksum is calculated as described in Mobility Header. The checksum is calculated as described in
[RFC3775]. [RFC3775].
Binding Revocation Type Binding Revocation Type
8-bit unsigned integer. It defines the type of the Binding 8-bit unsigned integer. It defines the type of the Binding
Revocation Message. It can be assigned one of the following Revocation Message. It can be assigned one of the following
values: values:
0 Reserved 0 Reserved
1 Binding Revocation Indication Message
2 Binding Revocation Acknowledgement Message 1 Binding Revocation Indication
All other values are reserved
2 Binding Revocation Acknowledgement
All other values are unassigned
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 document, it value in the Binding Revocation Type field. In this document, it
is either a Binding Revocation Indication as in Section 5.1 or is either a Binding Revocation Indication as in Section 5.1 or
Binding Revocation Acknowledgement as in Section 5.2. Binding Revocation Acknowledgement as in Section 5.2.
5.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 that has an MH type 16 and a Binding Revocation
Revocation Type value of 1. It is used by the initiator to inform Type value of 1. It is used by the initiator to inform the responder
the responder of the identity of a specific binding or bindings which of the identity of a specific binding or bindings for which IP
IP mobility service are being revoked. Binding Revocation Indication mobility service are being revoked. Binding Revocation Indication
message is sent as described in Section 7, Section 8.1, and message is sent as described in Sections 7, 8.1, and 9.2.
Section 9.2.
When the value 1 is indicated in the B. R. type field of the Binding When the value 1 is indicated in the Binding Revocation Type field of
Revocation Message, the format of the Binding Revocation Message Data the Binding Revocation Message, the format of the Binding Revocation
follows the Binding Revocation Indication message as in Figure 5 Message Data follows the Binding Revocation Indication message as in
Figure 5
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 1 | R. Trigger | | B.R. Type = 1 | R. Trigger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |P|V|G| Reserved | | Sequence # |P|V|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Binding Revocation Indication Message Figure 5: Binding Revocation Indication Message
Revocation Trigger Revocation Trigger
8-bit unsigned integer indicating the event which triggered the 8-bit unsigned integer indicating the event that triggered the
initiator to send the BRI message. The Per-MN Revocation Trigger initiator to send the BRI message. The Per-MN Revocation Trigger
values are less than 128. The per-MN revocation trigger is used values are less than 128. The Per-MN Revocation Trigger is used
when the BRI message intends to revoke one or more bindings for when the BRI message intends to revoke one or more bindings for
the same mobile node. The Global Revocation Trigger values are the same mobile node. The Global Revocation Trigger values are
greater than 128 and less than 250 and used in the BRI message greater than 128 and less than 250 and used in the BRI message
when the Global (G) bit is set for global revocation. The values when the Global (G) bit is set for global revocation. The values
250-255 are reserved for testing purposes only. The following 250-255 are reserved for testing purposes only. The following
Revocation Trigger values are currently defined: Revocation Trigger values are currently defined:
Per-MN Revocation Trigger Values: Per-MN Revocation Trigger Values:
0 Unspecified 0 Unspecified
1 Administrative Reason 1 Administrative Reason
2 Inter-MAG Handover - same Access Type 2 Inter-MAG Handover - same Access Type
3 Inter-MAG Handover - different Access Type 3 Inter-MAG Handover - different Access Type
4 Inter-MAG Handover - Unknown 4 Inter-MAG Handover - Unknown
5 User Initiated Session(s) Termination 5 User-Initiated Session(s) Termination
6 Access Network Session(s) Termination 6 Access Network Session(s) Termination
7 Possible Out-of Sync BCE State 7 Possible Out-of-Sync BCE State
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
Reserved Revocation Trigger Values: Reserved Revocation Trigger Values:
250-255 Reserved For Testing Purposes only 250-255 Reserved For Testing Purposes only
All other values are Reserved All other values are Reserved
Sequence # Sequence Number
A 16-bit unsigned integer used by the initiator to match a A 16-bit unsigned integer used by the initiator to match a
returned Binding Revocation Acknowledgement with this Binding returned Binding Revocation Acknowledgement with this Binding
Revocation Indication. This sequence number could be a random Revocation Indication. This sequence number could be a random
number. At any time, implementations MUST ensure there is no number. At any time, implementations MUST ensure there is no
collision between the sequence numbers of all outstanding Binding collision between the sequence numbers of all outstanding Binding
Revocation Indication Messages. Revocation Indication Messages.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set by the initiator to indicate that The Proxy Binding (P) bit is set by the initiator to indicate that
the revoked binding(s) is a PMIPv6 binding. 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 initiator, home The IPv4 HoA Binding Only (V) bit is set by the initiator, home
agent or local mobility anchor, to indicate to the receiving agent, or local mobility anchor to indicate to the receiving
mobility entity the termination of the IPv4 Home Address binding mobility entity the termination of the IPv4 Home Address binding
only as in Section 7, and Section 8.1. only as in Sections 7 and 8.1.
Global (G) Global (G)
The Global (G) bit is set by the initiator, LMA or MAG, to The Global (G) bit is set by the initiator, LMA or MAG, to
indicate the termination of all Per-Peer mobility Bindings or indicate the termination of all Per-Peer mobility Bindings or
Multiple Bindings which share a common identifier(s) and served by Multiple Bindings that share a common identifier(s) and are served
the initiator and responder as in Section 8.1 and Section 9.2. by the initiator and responder as in Sections 8.1 and 9.2.
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 A 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 that it does not understand. These mobility
option(s) are used by the responder to identify the specific options are used by the responder to identify the specific binding
binding or bindings that the initiator requesting to be revoked. or bindings that the initiator is requesting 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
only when the (P) bit is set. This option MUST be present when only when the (P) bit is set. This option MUST be present when
the BRI is used to revoke a single Proxy MIPv6 binding cache the BRI is used to revoke a single Proxy MIPv6 Binding Cache
entry. entry.
o Mobile Node Identifier Option [RFC4283]. This option MUST be o Mobile Node Identifier option [RFC4283]. This option MUST be
present when the (P) bit is set. Additionally, if the Global (G) present when the (P) bit is set. Additionally, if the Global (G)
bit is set by the mobile access gateway, this option MUST carry bit is set by the mobile access gateway, this option MUST carry
the MAG identity. In this specification, only Mobile Node the MAG identity. In this specification, only the Mobile Node
Identifier option with subtype 1 is required and other subtypes Identifier option with subtype 1 is required and other subtypes
are currently not supported. are currently not supported.
o Binding Identifier mobility option [RFC5648]. This option MUST be o Binding Identifier mobility option [RFC5648]. This option MUST be
present if the initiator requests to terminate one binding of a present if the initiator requests to terminate one binding of a
multiple care-of addresses bindings for the same mobile node. The multiple care-of address bindings for the same mobile node. The
initiator may include more than one of the BID mobility options. initiator may include more than one of 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 MUST only be included when the address [RFC5555]. This option MUST only be included when the
IPv4 HoA Binding only (V) bit is set. IPv4 HoA Binding only (V) bit is set and the (P) bit is cleared.
o IPv4 Home Address Request option, which contains the mobile node
proxy home IPv4 address [RFC5844]. This option MUST only be
included when the IPv4 HoA Binding only (V) and the (P) bits are
set.
o Alternate Care-of Address mobility option [RFC3775]. According to o Alternate Care-of Address mobility option [RFC3775]. According to
[RFC5213], the mobile access gateway is allowed to include this [RFC5213], the mobile access gateway is allowed to include this
option in the Proxy Binding Update to indicate the proxy Care-of option in the Proxy Binding Update to indicate the proxy care-of
address of the mobile node mobility session. This option MAY be address of the mobile node mobility session. This option MAY be
included to indicate the proxy Care-of address of the mobile included to indicate the proxy 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 is set, this option identifies all mobility bindings that (G) bit is set, this option identifies all mobility bindings that
share the same proxy care-of address. share the same proxy care-of address.
If no mobility options are present in this message, 4 octets of If no mobility options are present in this message, 4 octets of
padding are necessary and the Header Len field of the Binding padding are necessary and the Header Len field of the Binding
Revocation Message will be set to 1. Revocation Message will be set to 1.
5.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 that has an MH type 16 and a Binding Revocation
Revocation Type value of 2. It is used to acknowledge the receipt of Type value of 2. It is used to acknowledge the receipt of a Binding
a Binding Revocation Indication message described in Section 5.1. Revocation Indication message described in Section 5.1. This packet
This packet is sent as described in Section 6.1.2. is sent as described in Section 6.1.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 .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding Revocation Acknowledgement Message Figure 6: Binding Revocation Acknowledgement Message
Status Status 8-bit unsigned integer indicating the result of processing
the Binding Revocation Indication message by the responder.
8-bit unsigned integer indicating the result of processing the Values of the Status field less than 128 indicate that the Binding
Binding Revocation Indication message by the responder. Values of
the Status field less than 128 indicate that the Binding
Revocation Indication was processed successfully by the responder. Revocation Indication was processed successfully by the responder.
Values greater than or equal to 128 indicate that the Binding Values greater than or equal to 128 indicate that the Binding
Revocation Indication was rejected by the responder. The Revocation Indication was rejected by the responder. The
following status values are currently defined: following Status values are currently defined:
0 success 0 success
1 partial success 1 partial success
128 Binding Does NOT Exist 128 Binding Does NOT Exist
129 IPv4 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
135 Proxy Binding Revocation NOT Supported 135 Proxy Binding Revocation NOT Supported
Sequence # Sequence Number
The sequence number in the Binding Revocation Acknowledgement is The sequence number in the Binding Revocation Acknowledgement is
copied from the Sequence Number field in the Binding Revocation copied from the Sequence Number field in the Binding Revocation
Indication. It is used by the initiator, e.g., HA, LMA, MAG, in Indication. It is used by the initiator, e.g., HA, LMA, MAG, in
matching this Binding Revocation Acknowledgement with the matching this Binding Revocation Acknowledgement with the
outstanding Binding Revocation Indication. outstanding Binding Revocation Indication.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set if the (P) bit is set in the The Proxy Binding (P) bit is set if the (P) bit is set in the
skipping to change at page 18, line 12 skipping to change at page 17, line 35
The Global (G) bit is set if the (G) bit is set in the The Global (G) bit is set if the (G) bit is set in the
corresponding Binding Revocation Indication message. corresponding Binding Revocation Indication 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 A variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. In the case contains zero or more TLV-encoded mobility options. In the case
when the Status field is set to success, no mobility option is when the Status field is set to success, no mobility option is
required. The mobility option(s) is usually used to communicate required. The mobility option(s) is usually used to communicate
information of the bindings that failed the revocation procedure. information of the bindings that failed the revocation procedure.
The following 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
skipping to change at page 18, line 45 skipping to change at page 18, line 21
will be set to 1. will be set to 1.
6. Binding Revocation Process Operation 6. Binding Revocation Process Operation
The following subsections describe the details of the generic binding The following subsections describe the details of the generic binding
revocation process as used by the different mobility entities. revocation process as used by the different mobility entities.
6.1. Sending Binding Revocation Message 6.1. Sending Binding Revocation Message
When sending a Binding Revocation message, the initiator constructs When sending a Binding Revocation message, the initiator constructs
the packet as it would any other Mobility Header with the exception the packet as it would do with any other Mobility Header with the
of setting the MH Type field to <IANA-TBD>. exception of setting the MH Type field to 16.
The Binding Revocation Message MUST be protected using the same The Binding Revocation Message MUST be protected using the same
underlying security association, e.g., IPsec, that is being used underlying security association, e.g., IPsec, that is being used
between the two peers to protect the mobile node's Mobile IPv6 and between the two peers to protect the mobile node's Mobile IPv6 and
its extensions binding registration signaling. If IPsec is not used its extensions binding registration signaling. If IPsec is not used
as the underlying security mechanism to protect the binding as the underlying security mechanism to protect the binding
registration signaling, the used underlying security mechanism MUST registration signaling, the used underlying security mechanism MUST
provide protection against all identified security threats as provide protection against all identified security threats as
described under Security Considerations in [RFC3775] and [RFC5213]. described under "Security Considerations" in [RFC3775] and [RFC5213].
6.1.1. Sending Binding Revocation Indication 6.1.1. Sending Binding Revocation Indication
The initiator MUST construct the Binding Revocation Message Data The initiator MUST construct the Binding Revocation Message Data
following the format of the Binding Revocation Indication message as following the format of the Binding Revocation Indication message as
described in Section 5.1 and the following: described in Section 5.1 and the following:
o The initiator MUST set the Sequence Number field to a valid o The initiator MUST set the Sequence Number field to a valid
sequence number for Binding Revocation. Since sending Binding sequence number for Binding Revocation. Since sending a Binding
Revocation Indication message is not done on a regular basis, a 16 Revocation Indication message is not done on a regular basis, a
bit sequence number field is large enough to allow the initiator 16-bit Sequence Number field is large enough to allow the
to match the Binding Revocation Acknowledgement to the associated initiator to match the Binding Revocation Acknowledgement to the
Binding Revocation Indication using the sequence number field associated Binding Revocation Indication using the Sequence Number
only. field only.
o If the initiator is revoking a binding that was created using o If the initiator is revoking a binding that was created using
proxy MIPv6 registration, the initiator MUST set the Proxy Binding proxy MIPv6 registration, the initiator MUST set the Proxy Binding
(P) bit. (P) bit.
o If the initiator is sending the Binding Revocation Indication o If the initiator is sending the Binding Revocation Indication
message to revoke multiple mobility sessions, the initiator MUST message to revoke multiple mobility sessions, the initiator MUST
set the Global (G) bit. In this case, the initiator MUST set the set the Global (G) bit. In this case, the initiator MUST set the
revocation trigger field to a valid value from the list of Global Revocation Trigger field to a valid value from the list of Global
Revocation Triggers. Revocation Triggers.
o If the initiator is sending the Binding Revocation Indication o If the initiator is sending the Binding Revocation Indication
message with the Global (G) bit cleared, the initiator MUST set message with the Global (G) bit cleared, the initiator MUST set
the revocation trigger field to a valid value from the list of the Revocation Trigger field to a valid value from the list of
per-MN Revocation Triggers. Per-MN Revocation Triggers.
o If the initiator is sending the Binding Revocation Indication o If the initiator is sending the Binding Revocation Indication
message to indicate the revocation of the mobile node IPv4 HoA message to indicate the revocation of the mobile node IPv4 HoA
Binding Only, the initiator MUST set the (V) bit. In this case, Binding Only, the initiator MUST set the (V) bit. In this case,
the initiator MUST include the IPv4 Home Address option in the BRI the initiator MUST include either the IPv4 Home Address option or
to identify the IPv4 HoA that is being revoked. the IPv4 Home Address Request option in the BRI to identify the
IPv4 HoA that is being revoked.
6.1.2. Sending Binding Revocation Acknowledgement 6.1.2. Sending Binding Revocation Acknowledgement
The responder MUST send a Binding Revocation Acknowledgement message The responder MUST send a Binding Revocation Acknowledgement message
to indicate the receipt and the status of processing of the to indicate the receipt and the status of processing of the
corresponding Binding Revocation Indication message as follows: corresponding Binding Revocation Indication message as follows:
o Whenever the Binding Revocation Indication is discarded, e.g., as o Whenever the Binding Revocation Indication is discarded, e.g., as
described in Section 6.2, a Binding Revocation Acknowledgement described in Section 6.2, a Binding Revocation Acknowledgement
MUST NOT be sent. Otherwise the treatment depends on the MUST NOT be sent. Otherwise, the treatment depends on the
following rules. following rules.
o If the responder accepts the Binding Revocation Indication o If the responder accepts the Binding Revocation Indication
message, the responder MUST send a successful Binding Revocation message, the responder MUST send a successful Binding Revocation
Acknowledgement with an appropriate status code. Acknowledgement with an appropriate status code.
o If the responder rejects the Binding Revocation Indication o If the responder rejects the Binding Revocation Indication
message, the responder MUST send a Binding Revocation message, the responder MUST send a Binding Revocation
Acknowledgement with an appropriate failure status code. Acknowledgement with an appropriate failure status code.
skipping to change at page 20, line 33 skipping to change at page 20, line 9
When the responder acknowledges the received Binding Revocation When the responder acknowledges the received Binding Revocation
Indication message, the responder MUST construct the Binding Indication message, the responder MUST construct the Binding
Revocation Message Data following the format of the Binding Revocation Message Data following the format of the Binding
Revocation Acknowledgement message as described in Section 5.2 and Revocation Acknowledgement message as described in Section 5.2 and
the following: the following:
o The responder MUST set the Sequence Number field by copying the o The responder MUST set the Sequence Number field by copying the
value from the Sequence Number field of the received Binding value from the Sequence Number field of the received Binding
Revocation Indication. Revocation Indication.
o The responder MUST set the status field to a valid value that o The responder MUST set the Status field to a valid value that
reflects the status of the processing of the received Binding reflects the status of the processing of the received Binding
Revocation Indication message. Revocation Indication message.
o If the (P) bit is set in the received Binding Revocation o If the (P) bit is set in the received Binding Revocation
Indication, the responder MUST set the (P) bit in the Binding Indication, the responder MUST set the (P) bit in the Binding
Revocation Acknowledgement. Revocation Acknowledgement.
o If the Global (G) bit is set in the received Binding Revocation o If the Global (G) bit is set in the received Binding Revocation
Indication, the responder MUST set the Global (G) bit in the Indication, the responder MUST set the Global (G) bit in the
Binding Revocation Acknowledgement. Binding Revocation Acknowledgement.
skipping to change at page 21, line 7 skipping to change at page 20, line 31
o If the IPv4 HoA Binding Only (V) bit is set in the received o If the IPv4 HoA Binding Only (V) bit is set in the received
Binding Revocation Indication, the responder MUST set the (V) bit Binding Revocation Indication, the responder MUST set the (V) bit
in the Binding Revocation Acknowledgement. in the Binding Revocation Acknowledgement.
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.
6.2. Receiving Binding Revocation Message 6.2. Receiving Binding Revocation Message
When receiving a Binding Revocation message, the responder MUST When receiving a Binding Revocation Message, the responder MUST
verify the Mobility Header as described in section 9.2. of [RFC3775]. verify the Mobility Header as described in Section 9.2. of [RFC3775].
If the packet is dropped due to failing any of the Mobility Headers If the packet is dropped due to failing any of the Mobility Header
test check, the responder MUST follow the processing rules as in test checks, the responder MUST follow the processing rules as in
Section 9.2 of [RFC3775]. If the responder does not support the Section 9.2 of [RFC3775]. If the responder does not support the
Binding Revocation Indication message and does not recognize the MH Binding Revocation Indication message and does not recognize the MH
type <IANA-TBD>, it sends a Binding Error message with the Status type 16, it sends a Binding Error message with the Status field set
field set to 2 as described in [RFC3775]. to 2 as described in [RFC3775].
Upon receiving a packet carrying a Binding Revocation Message, BRI or Upon receiving a packet carrying a Binding Revocation Message, BRI or
BRA, the receiving mobility entity MUST verify that the packet was BRA, the receiving mobility entity MUST verify that the packet was
received protected by the security association that is being used to received protected by the security association that is being used to
protect the binding registration and Binding Revocation signaling protect the binding registration and Binding Revocation signaling
between the two peers, e.g., an IPsec SA. between the two peers, e.g., an IPsec Security Association (SA).
6.2.1. Receiving Binding Revocation Indication 6.2.1. Receiving Binding Revocation Indication
When the responder receives a packet carrying a Binding Revocation When the responder receives a packet carrying a Binding Revocation
Indication message that was successfully processed as in Section 6.2, Indication message that was successfully processed as in Section 6.2,
the responder, in addition, processes the message as follows: the responder, in addition, processes the message as follows:
o The responder MUST validate that the Binding Revocation Indication o The responder MUST validate that the Binding Revocation Indication
is formatted as in Section 5.1. is formatted as in Section 5.1.
o If the Revocation Trigger field is set to a value that the o If the Revocation Trigger field is set to a value that the
responder does not support, the responder SHOULD reject the responder does not support, the responder SHOULD reject the
Binding Revocation Indication message using status code Binding Revocation Indication message using status code
"Revocation Trigger NOT Supported". "Revocation Trigger NOT Supported".
o If the Revocation Trigger value is NOT allowed with the Binding o If the Revocation Trigger value is NOT allowed with the Binding
Revocation Indication message intent, e.g., the Global (G) bit is Revocation Indication message intent, e.g., the Global (G) bit is
set and the Revocation Trigger field value is a per-MN specific, set and the Revocation Trigger field value is Per-MN-specific, the
the responder SHOULD reject the Binding Revocation Indication responder SHOULD reject the Binding Revocation Indication message
message using status code "Revocation Function NOT Supported". using status code "Revocation Function NOT Supported".
o If the responder failed to identify the mobile node(s) bindings as o If the responder failed to identify the mobile node(s) bindings as
identified in the Binding Revocation Indication message, the identified in the Binding Revocation Indication message, the
responder MUST reject the BRI using Status code "Binding Does NOT responder MUST reject the BRI using status code "Binding Does NOT
Exist". Exist".
6.2.2. Receiving Binding Revocation Acknowledgement 6.2.2. Receiving Binding Revocation Acknowledgement
When the initiator receives a packet carrying a Binding Revocation When the initiator receives a packet carrying a Binding Revocation
Acknowledgement message that was successfully processed as in Acknowledgement message that was successfully processed as in
Section 6.2, the initiator, in addition, processes the message and Section 6.2, the initiator, in addition, processes the message and
examines the Status field as follows: examines the Status field as follows:
o The initiator MUST validate that the sequence number in the o The initiator MUST validate that the sequence number in the
skipping to change at page 22, line 30 skipping to change at page 22, line 10
Binding Revocation Acknowledgement. In this case, it is based on Binding Revocation Acknowledgement. In this case, it is based on
the initiator local policy how to handle the mobile node binding. the initiator local policy how to handle the mobile node binding.
The initiator MAY log the appropriate event to reflect the The initiator MAY log the appropriate event to reflect the
received status. received status.
6.3. Retransmission of Binding Revocation Indication 6.3. Retransmission of Binding Revocation Indication
If the initiator does not receive a Binding Revocation If the initiator does not receive a Binding Revocation
Acknowledgement in response to the outstanding Binding Revocation Acknowledgement in response to the outstanding Binding Revocation
Indication before the InitMINDelayBRIs timer expires, the initiator, Indication before the InitMINDelayBRIs timer expires, the initiator,
e.g. LMA, SHOULD retransmit the same BRI message up to the e.g., LMA, SHOULD retransmit the same BRI message up to the
BRIMaxRetriesNumber as defined in Section 11. BRIMaxRetriesNumber as defined in Section 11.
The retransmissions by the initiator MUST use an exponential back-off The retransmissions by the initiator MUST use an exponential back-off
process in which the timeout period is doubled upon each process in which the timeout period is doubled upon each
retransmission, until either the initiator receives a response or the retransmission, until either the initiator receives a response or the
timeout period reaches the value MAX_BRACK_TIMEOUT. The initiator timeout period reaches the value MAX_BRACK_TIMEOUT. The initiator
MAY continue to send these messages at this slower rate up to the MAY continue to send these messages at this slower rate up to the
BRIMaxRetriesNumber. BRIMaxRetriesNumber.
If the initiator does not receive a Binding Revocation If the initiator does not receive a Binding Revocation
Acknowledgement message after the BRIMaxRetriesNumber of retransmits Acknowledgement message after the BRIMaxRetriesNumber of retransmits
have been sent, the initiator SHOULD clean all resources associated have been sent, the initiator SHOULD clean up all resources
with this mobile node binding. The initiator may log the event. associated with this mobile node binding. The initiator may log the
event.
7. Home Agent Operation 7. Home Agent Operation
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 Revocation Trigger field MUST be set to indicate to the mobile o The Revocation Trigger field MUST be set to indicate to the mobile
node the reason for revoking its IP mobility binding with the home node the reason for revoking its IP mobility binding with the home
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 that 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. destination address in the packet's IPv6 header.
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.
skipping to change at page 23, line 36 skipping to change at page 23, line 15
in this state until it receives a Binding Revocation Acknowledgement in this state until it receives a Binding Revocation Acknowledgement
or retransmits the Binding Revocation Indication message as described or retransmits the Binding Revocation Indication message as described
in Section 6.3. 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 Multiple Care-of address bindings that were created using multiple care-of address
registration as in [RFC5648], the home agent MUST include all the registrations as in [RFC5648], the home agent MUST include all the
related BID mobility options that identify these bindings in the related BID mobility options that identify these bindings in the
Binding Revocation Indication message. In the case when the home Binding Revocation Indication message. In the case when the home
agent needs to revoke all of the mobile node bindings, the home agent agent needs to revoke all of the mobile node bindings, the home agent
SHOULD NOT include any of the BID mobility options. SHOULD NOT include any of the BID mobility options.
When the home agent receives a packet carrying a valid Binding When the home agent receives a packet carrying a valid Binding
Revocation Acknowledgement message, the home agent follows Revocation Acknowledgement message, the home agent follows
Section 6.2 in processing this message. Section 6.2 in processing this message.
8. Local Mobility Anchor Operation 8. Local Mobility Anchor Operation
8.1. Sending Binding Revocation Indication 8.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 6.1 Revocation Indication message following the procedure in Section 6.1
and the following rules: and the following rules:
o The Proxy Mobile IP (P) bit MUST be set to indicate that the o The Proxy Binding (P) bit MUST be set to indicate that the binding
binding being revoked is a PMIPv6 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 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 which contains the mobile node's Network Access Identifier (NAI)
Binding Update during the mobile node registration. 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 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 one of the mobile node's BCEs and the local mobility anchor does
NOT need to revoke all of the mobile node's bindings, the Binding NOT need to revoke all of the mobile node's bindings, the Binding
Revocation Indication message MUST contain another identifier to Revocation Indication message MUST contain another identifier to
uniquely identify the mobile node binding(s) that is being uniquely identify the mobile node binding(s) that is being
revoked, e.g., at least one Home Network Prefix option which revoked, e.g., at least one Home Network Prefix option that
contains the mobile node's registered Home Network Prefix (HNP) contains the mobile node's registered Home Network Prefix (HNP)
for the binding being revoked. for the binding being revoked.
o In case of revoking all Per-Peer bindings, the local mobility o In the case of revoking all Per-Peer bindings, the local mobility
anchor MUST set the Global (G) bit and the Revocation Trigger MUST anchor MUST set the Global (G) bit and the Revocation Trigger MUST
contain the value "Per-Peer Policy" to request the mobile access contain the value "Per-Peer Policy" to request the mobile access
gateway to remove all Per-Peer bindings that are registered with gateway to remove all Per-Peer bindings that are registered with
the local mobility anchor and this mobile access gateway. the local mobility anchor and this mobile access gateway.
o The proxy Care-of address for the binding MUST be used as the o The proxy care-of address for the binding MUST be used as the
destination address in the packet's IPv6. However, in the case destination address in the packet's IPv6 header. However, in the
when IPsec is used to protect the Proxy MIPv6 signaling as case when IPsec is used to protect the Proxy MIPv6 signaling as
specified in [RFC5213], the destination address MUST be set to the specified in [RFC5213], the destination address MUST be set to the
mag_address that is being used for keying the IPsec SA. If the mag_address that is being used for keying the IPsec SA. If the
mag_address is different than the mobile node proxy Care-of mag_address is different than the mobile node proxy care-of
address, the Alternate Care-of address option MUST be included and address, the Alternate Care-of Address option MUST be included and
MUST contain the mobile node proxy Care-of address. MUST contain the mobile node proxy care-of address.
The local mobility anchor MAY delete the mobile node(s) IP tunnel The local mobility anchor MAY delete the mobile node(s) IP tunnel
immediately after sending the initial Binding Revocation Indication immediately after sending the initial Binding Revocation Indication
and before receiving the Binding Revocation Acknowledgement message. and before receiving the 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, the local to the mobile access gateway to remove a specific binding, the local
mobility anchor sets a flag in the mobile node proxy BCE to indicate mobility anchor sets a flag in the mobile node proxy BCE to indicate
that revocation is in progress and starts the InitMINDelayBRIs timer. that revocation is in progress and starts the InitMINDelayBRIs timer.
The local mobility anchor SHOULD maintain the mobile node proxy BCE The local mobility anchor SHOULD maintain the mobile node proxy BCE
in this state until it receives a Binding Revocation Acknowledgement in this state until it receives a Binding Revocation Acknowledgement
or the BRIMaxRetransmitNumber is reached. In the case when the local or the 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 that
indicates inter-MAG handover, the local mobility anchor MAY switch indicates inter-MAG handover, the local mobility anchor MAY switch
the mobile node IP tunnel to the target mobile access gateway before the mobile node IP tunnel to the target mobile access gateway before
sending the Binding Revocation Indication to the source mobile access sending the Binding Revocation Indication to the source mobile access
gateway. gateway.
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 the mobile nodes When the local mobility anchor needs to revoke all the mobile node
proxy BCEs that are registered with the local mobility anchor and the proxy BCEs that are registered with the local mobility anchor and the
mobile access gateway peer, it MUST set the Global (G) bit and set mobile access gateway peer, it MUST set the Global (G) bit and set
the value of the Revocation Trigger field to "Per-Peer Policy". In the value of the Revocation Trigger field to "Per-Peer Policy". In
this case, the local mobility anchor MUST NOT include any mobility this case, the local mobility anchor MUST NOT include any mobility
options in this Binding Revocation Indication message. options in 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
BCEs that belong to a specific realm and are registered with the BCEs that belong to a specific realm and are registered with the
local mobility anchor and the mobile access gateway peer, the local local mobility anchor and the mobile access gateway peer, the local
mobility anchor MUST set the Global (G) bit and set the value of the mobility anchor MUST set the Global (G) bit and set the value of the
Revocation Trigger field to "Revoking Mobility Node Local Policy". Revocation Trigger field to "Revoking Mobility Node Local Policy".
In this case, the local mobility anchor MUST include a mobility In this case, the local mobility anchor MUST include a mobility
option in the Binding Revocation Indication that is shared among all option in the Binding Revocation Indication that is shared among all
the impacted mobile nodes BCEs, e.g., the mobile node identifier the impacted mobile nodes BCEs, e.g., the mobile node identifier
option, MN-ID option, with subtype value of 1. In this case, the NAI option, MN-ID option, with a subtype value of 1. In this case, the
value in the MN-ID MUST follow the format where the content after the NAI value in the MN-ID MUST follow the format where the content after
"@" character defines the realm which is shared amongst all of the the "@" character defines the realm that is shared amongst all of the
impacted mobile nodes proxy BCEs. As an example: @example.com impacted mobile nodes proxy BCEs. As an example: @example.com
identifies all mobile nodes which their MN-ID value contain identifies all mobile nodes whose MN-ID value contains "example.com"
"example.com" as the realm, e.g., "1234abdelta@example.com", as the realm, e.g., "1234abdelta@example.com", "axxxyzd@example.com",
"axxxyzd@example.com", and "abcdefg.xyz123@example.com", but not and "abcdefg.xyz123@example.com", but not
"1234abdelta@foo.example.com". "1234abdelta@foo.example.com".
When the local mobility anchor needs to revoke a subgroup of the When the local mobility anchor needs to revoke a subgroup of the
mobile nodes proxy BCEs that belong to a specific realm and are mobile nodes proxy BCEs that belong to a specific realm and are
registered with the local mobility anchor and the mobile access registered with the local mobility anchor and the mobile access
gateway, the local mobility anchor MUST set the Global (G) bit and gateway, the local mobility anchor MUST set the Global (G) bit and
set the value of the Revocation Trigger field to "Revoking Mobility set the value of the Revocation Trigger field to "Revoking Mobility
Node Local Policy". In this case, the local mobility anchor MUST Node Local Policy". In this case, the local mobility anchor MUST
include an additional mobility option to the mobile node identifier include an additional mobility option to the mobile node identifier
option, MN-ID option, with subtype value of 1. In other words, the option (MN-ID) option, with a subtype value of 1. In other words,
impacted mobile node BCEs are those which have a MN-ID with a realm the impacted mobile node BCEs are those that have an MN-ID with a
as specified above and, e.g., are assigned the same proxy care-of realm as specified above and, e.g., are assigned the same proxy
address as the one included in the Alternate Care-of address mobility care-of address as the one included in the Alternate Care-of Address
option. 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 an 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 with the mobile node NAI the mobile node identifier (MN-ID) option with the mobile node NAI
included to indicate to the mobile access gateway to remove all included to indicate to the mobile access gateway to remove all
bindings of the specified mobile node 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 the Proxy Mobile IPv6 specification [RFC5213], if the
mobility anchor receives a Proxy Binding Update message from a new local mobility anchor receives a Proxy Binding Update message from a
mobile access gateway for extending the binding lifetime of the only new mobile access gateway for extending the binding lifetime of the
BCE of this mobile node with the Handoff Indicator value is set to only BCE of this mobile node with the Handoff Indicator value set to
"Inter-MAG Handover - Unknown", the local mobility anchor waits a "Handoff state unknown (4)", the local mobility anchor waits a period
period of MaxDelayBeforeNewBCEAssign to receive a de-registration of MaxDelayBeforeNewBCEAssign to receive a de-registration message
message from the previous mobile access gateway before updating the from the previous mobile access gateway before updating the mobile
mobile node's BCE with the new point of attachment. If a de- node's BCE with the new point of attachment. If a de-registration
registration message is not received, the local mobility anchor message is not received, the local mobility anchor considers the
considers the received Proxy Binding Update message as a request for received Proxy Binding Update message as a request for a new BCE and
a new BCE and if processed successfully, the local mobility anchor if processed successfully, the local mobility anchor assigns a
assigns a different HNP for the new BCE. different HNP for the new BCE.
This document updates the local mobility anchor's behavior in this This document updates the local mobility anchor's behavior in this
case. If the local mobility anchor supports the binding revocation case. If the local mobility anchor supports the binding revocation
mechanism as described in this document, it SHOULD proactively send a mechanism as described in this document, it SHOULD proactively send a
Binding Revocation Indication message to the previous mobile access Binding Revocation Indication message to the previous mobile access
gateway instead of waiting for a de-registration from the previous gateway instead of waiting for a de-registration from the previous
mobile access gateway. In the Binding Revocation Indication message, mobile access gateway. In the Binding Revocation Indication message,
the Revocation Trigger MUST be set to "Inter-MAG Handover - Unknown". the Revocation Trigger MUST be set to "Inter-MAG Handover - Unknown".
If the local mobility anchor sent a Binding Revocation Indication If the local mobility anchor sent a Binding Revocation Indication
message with the Revocation Trigger field set to "Inter-MAG Handover message with the Revocation Trigger field set to "Inter-MAG Handover
- Unknown" and while waiting for a Binding Revocation - Unknown" and while waiting for a response, Binding Revocation
Acknowledgement, the following are possible conditions that the local Acknowledgement, the following are possible conditions that the local
mobility anchor MUST handle as specified below: mobility anchor MUST handle as specified below:
o If the local mobility anchor receives a successful Binding o If the local mobility anchor receives a successful Binding
Revocation Acknowledgement message or a de-registration message Revocation Acknowledgement message or a de-registration message
from the previous mobile access gateway, the local mobility anchor from the previous mobile access gateway, the local mobility anchor
MUST update the mobile node BCE in a similar way as if it received MUST update the mobile node BCE as if it received a de-
a de-registration message as described in [RFC5213]. registration message as described in [RFC5213].
o If the local mobility anchor receives a Binding Revocation o If the local mobility anchor receives a Binding Revocation
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 as if it did NOT receive a de-registration
de-registration before the MaxDelayBeforeNewBCEAssign timer before the MaxDelayBeforeNewBCEAssign timer expired by creating a
expires by creating a new BCE as described in [RFC5213]. 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 or 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 6.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 as if it did NOT receive a de-registration
de-registration before the MaxDelayBeforeNewBCEAssign timer before the MaxDelayBeforeNewBCEAssign timer expired by creating a
expires by creating a new BCE as described in [RFC5213]. Note new BCE as described in [RFC5213]. Note that the local mobility
that the local mobility anchor SHOULD use the recommended number anchor SHOULD use the recommended number of retransmissions for
of retransmissions for the Binding Revocation Indication message the Binding Revocation Indication message as described in
as described in Section 11 to avoid delaying the creation of a new Section 11 to avoid delaying the creation of a new Binding Cache
binding cache entry for too long, if the mobile node is actually entry for too long, if the mobile node is actually attaching to
attaching to the new MAG with a different interface. 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 proxy HoA
HNP are bound to the same proxy CoA, the local mobility anchor MAY (pHoA) and HNP are bound to the same proxy CoA (pCoA), the local
revoke the mobile node IPv4 proxy HoA binding to the current mobile mobility anchor MAY revoke the mobile node IPv4 proxy HoA binding to
node proxy CoA while maintaining the mobile node binding of the HNP the current mobile node proxy CoA while maintaining the mobile node
to its current pCoA as part of the mobile node BCE. In this case, if binding of the HNP to its current pCoA as part of the mobile node
the local mobility anchor decides to revoke the mobile node IPv4 BCE. In this case, if the local mobility anchor decides to revoke
proxy HoA only, it MUST send a Binding Revocation Indication message the mobile node IPv4 proxy HoA only, it MUST send a Binding
following the procedure in Section 6.1 and the following rules: Revocation Indication message 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 IPv4 Home Address option MUST be included with the mobile o The IPv4 Home Address Request option MUST be included with the
node's registered IPv4 home address that is being released in mobile node's registered proxy home IPv4 address that is being
addition to the MN-ID option. released in 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".
8.2. Receiving Binding Revocation Indication 8.2. 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 6.2, in addition, the local mobility anchor processes the Section 6.2, the local mobility anchor processes the message as
message as follows: follows:
o If the (P) bit is set, the local mobility anchor MUST validate o If the (P) bit is set, the local mobility anchor MUST validate
that all impacted binding(s) have the proxy binding flag set. that all impacted bindings have the proxy binding flag set.
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 LMA MUST validate that the Proxy value is "Per-Peer Policy", the LMA MUST validate that the Proxy
(P) bit is set and the MN-ID option is present with the mobile (P) bit is set and the MN-ID option is present with the mobile
access gateway identity included. In addition, the local mobility access gateway identity included. In addition, the local mobility
anchor MUST verify that the identified mobile access gateway as anchor MUST verify that the identified mobile access gateway as
per the value in the MN-ID option is authorized to use the global per the value in the MN-ID option is authorized to use the global
revocation with revocation trigger value "Per-Peer Policy", see revocation with revocation trigger value "Per-Peer Policy", see
Section 13. If the local mobility anchor processes the Global Section 13. If the local mobility anchor processes the Global
Binding Revocation Indication message successfully, it MUST accept Binding Revocation Indication message successfully, it MUST accept
the Binding Revocation Indication message using the Status code the Binding Revocation Indication message using the status code
success. "success".
o If the mobile access gateway is not authorized to use the Per-Peer o If the mobile access gateway is not authorized to use the Per-Peer
Global revocation feature or the received Binding Revocation Global revocation feature or the received Binding Revocation
Indication message has the Global (G) bit set and the Revocation Indication message has the Global (G) bit set and the Revocation
Trigger field is set to "Per-Peer Policy", but the MN-ID option is Trigger field is set to "Per-Peer Policy", but the MN-ID option is
not included, the local mobility anchor MUST reject the Binding not included, the local mobility anchor MUST reject the Binding
Revocation Indication message using Status code (Global Revocation Revocation Indication message using status code "Global Revocation
NOT Authorized). NOT Authorized".
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 node bindings for which the proxy CoA is the one used as
source of the IPv6 packet that carried the Binding Revocation the source of the IPv6 packet that carried the Binding Revocation
Indication. However, if Alternate Care-of Address option is Indication. However, if the Alternate Care-of Address option is
included in addition to the mobile node identifier option, the included in addition to the mobile node identifier option, the
local mobility anchor MUST revoke all mobile nodes bindings which local mobility anchor MUST revoke all mobile node bindings whose
proxy Care-of Address matches the Care-of address in the Alternate proxy care-of address matches the care-of address in the Alternate
Care-of Address option. After the local mobility anchor Care-of Address option. After the local mobility anchor
successfully processes the Binding Revocation Indication message successfully processes the Binding Revocation Indication message
and identifies all impacted mobile nodes bindings, it MUST accept and identifies all impacted mobile nodes bindings, it MUST accept
the Binding Revocation Indication message using the Status code the Binding Revocation Indication message using the status code
success. "success".
o If the local mobility anchor accepted the Binding Revocation o If the local mobility anchor accepted the Binding Revocation
Indication message but one or more of the bindings identified in Indication message but one or more of the bindings identified in
the received Binding Revocation Indication message has already the received Binding Revocation Indication message has already
been released, the local mobility anchor MUST accept the message been released, the local mobility anchor MUST accept the message
and it MAY set the Status field to (partial success) and include and it MAY set the Status field to "partial success" and include
the mobile node identifier, MN-ID, or the Home Network Prefix the mobile node identifier (MN-ID) or the Home Network Prefix
option to identify the binding(s) that failed the revocation option to identify the binding(s) that failed the revocation
procedure. procedure.
o If the Global (G) bit is not set, the local mobility anchor uses o If the Global (G) bit is not set, the local mobility anchor uses
the included mobility options to identify the impacted mobile node the included mobility options to identify the impacted mobile node
binding as follows: 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 accept the message and revoke the local mobility anchor MUST accept the message and revoke
all bindings for this mobile node which use the specified all bindings for this mobile node that use the specified
mobile node NAI including the IPv4 Home Address binding(s) if mobile node NAI including the IPv4 Home Address binding(s) if
present. present.
2. If the mobile node identifier, MN-ID, and one Home Network 2. If the mobile node identifier (MN-ID) and one Home Network
Prefix option are included, the local mobility anchor MUST Prefix option are included, the local mobility anchor MUST
accept the message and only remove the specified mobile node accept the message and only remove the specified mobile node
proxy binding. 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 accept the message and remove all bindings which anchor MUST accept the message and remove all bindings that
are referenced by these Home Network Prefixes for the are referenced by these Home Network Prefixes for the
specified mobile node NAI. specified mobile node NAI.
4. If the IPv4 HoA binding Only (V) bit is set and the mobile 4. If the IPv4 HoA binding Only (V) bit is set and the mobile
node identifier, MN-ID, option and the IPv4 Home Address node identifier (MN-ID) option and the IPv4 Home Address
option are included, the local mobility anchor MUST accept the Request option are included, the local mobility anchor MUST
message and remove only the IPv4 HoA address binding to the accept the message and remove only the IPv4 HoA address
mobile node current proxy Care-of 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 that track the state of the peer
mobile access gateway. mobile access gateway.
After the local mobility anchor accepts or rejects a Binding After the local mobility anchor accepts or rejects a Binding
Revocation Indication message, the local mobility anchor MUST follow Revocation Indication message, the local mobility anchor MUST follow
Section 6.1 and Section 6.1.2 to send a Binding Revocation Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement
Acknowledgement message to the mobile access gateway. message to the mobile access gateway.
9. Mobile Access Gateway Operation 9. Mobile Access Gateway Operation
9.1. Receiving Binding Revocation Indication 9.1. Receiving Binding Revocation Indication
When the mobile access gateway receives a packet carrying a Binding When the mobile access gateway receives a packet carrying a Binding
Revocation Indication that was successfully processed as in Revocation Indication that was successfully processed as in
Section 6.2, in addition, the mobile access gateway processes the Section 6.2, the mobile access gateway processes the message as
message as follows: follows:
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 MUST value is "Per-Peer Policy", the mobile access gateway MUST
validate that the Proxy (P) bit is set and no mobility options is validate that the Proxy (P) bit is set and no mobility options are
included in the message. If the mobile access gateway processes included in the message. If the mobile access gateway processes
the Global Binding Revocation Indication message successfully, it the Global Binding Revocation Indication message successfully, it
MUST accept the Binding Revocation Indication message using the MUST accept the Binding Revocation Indication message using the
Status code success. status code "success".
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 validate that the Proxy (P) bit is set and at least gateway MUST validate that the Proxy (P) bit is set and at least
the MN-ID option with the subtype value of 1 is included in the the MN-ID option with the subtype value of 1 is included in the
Binding Revocation Indication and it is formatted as described is Binding Revocation Indication and it is formatted as described is
Section 8.1. If the mobile access gateway processes this Global Section 8.1. If the mobile access gateway processes this Global
Binding Revocation Indication message successfully, it MUST accept Binding Revocation Indication message successfully, it MUST accept
the message using the Status code success. the message using the status code "success".
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 MUST reject the Binding this case, the mobile access gateway MUST reject the Binding
Revocation Indication message using Status code "Revoked Mobile Revocation Indication message using status code "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, the mobile access gateway uses the Inter-MAG Handover - Unknown, the mobile access gateway uses the
mobility option(s) included in the Binding Revocation Indication mobility option(s) included in the Binding Revocation Indication
message to identify the mobile node binding. The mobile access message to identify the mobile node binding. The mobile access
gateway SHOULD ensure that the mobile node is no longer attached gateway SHOULD ensure that the mobile node is no longer attached
to the mobile access gateway before accepting the BRI message to the mobile access gateway before accepting the BRI message
using Status code success. However, if the mobile access gateway using status code "success". However, if the mobile access
verified that the mobile node is still directly attached, the gateway verified that the mobile node is still directly attached,
mobile access gateway MUST reject the BRI using Status code the mobile access gateway MUST reject the BRI using status code
"Revocation failed - MN is Attached". "Revocation failed - MN is Attached".
o If the IPv4 HoA Binding Only (V) bit is set, the mobile access o If the IPv4 HoA Binding Only (V) bit is set, the mobile access
gateway uses the MN-ID option to identify the mobile node binding gateway uses the MN-ID option to identify the mobile node binding
entry in the Binding Update List (BUL). The mobile access gateway entry in the Binding Update List (BUL). The mobile access gateway
MUST verify that the IPv4 address included in the IPv4 Home MUST verify that the IPv4 address included in the IPv4 Home
Address option in the received Binding Revocation Indication is Address Request option in the received Binding Revocation
the same as the IPv4 proxy HoA that is assigned to the mobile Indication is the same as the IPv4 proxy HoA that is assigned to
node. After the mobile access gateway successfully validates the the mobile node. After the mobile access gateway successfully
received IPv4 home address as the mobile node IPv4 HoA, it MUST validates the received IPv4 home address as the mobile node IPv4
consider this as an indication to ONLY release the mobile node HoA, it MUST consider this as an indication to ONLY release the
IPv4 proxy HoA binding to the mobile node current proxy CoA. mobile node IPv4 proxy HoA binding to the mobile node current
Consequently, it MUST continue to maintain the mobile node IPv6 proxy CoA. Consequently, it MUST continue to maintain the mobile
proxy HoA or HNP binding to the current mobile node proxy CoA as node IPv6 proxy HoA or HNP binding to the current mobile node
part of the mobile node binding in the BUL entry and release all proxy CoA as part of the mobile node binding in the BUL entry and
resources associated with the MN IPv4 proxy HoA binding to the MN release all resources associated with the MN IPv4 proxy HoA
pCoA. If the mobile access gateway processed the BRI binding to the MN pCoA. If the mobile access gateway processed
successfully, the mobile access gateway MUST accept the BRI using the BRI successfully, the mobile access gateway MUST accept the
Status code success. On the other hand, if the mobile access BRI using status code "success". On the other hand, if the mobile
gateway is able to identify the mobile node binding using the access gateway is able to identify the mobile node binding using
MN-ID but failed to identify the received IPv4 proxy HoA, the the MN-ID but failed to identify the received IPv4 proxy HoA, the
mobile access gateway MUST reject the BRI using Status code mobile access gateway MUST reject the BRI using status code
"Binding Does NOT Exist". "Binding Does NOT Exist".
o If the mobile access gateway accepts the Binding Revocation o If the mobile access gateway accepts the Binding Revocation
Indication message but one or more of the bindings identified in Indication message but one or more of the bindings identified in
the received Binding Revocation Indication message has already the received Binding Revocation Indication message has already
been released before processing the Binding Revocation Indication, been released before processing the Binding Revocation Indication,
the mobile access gateway MUST accept the Binding Revocation the mobile access gateway MUST accept the Binding Revocation
Indication message. In this case, the mobile access gateway MAY Indication message. In this case, the mobile access gateway MAY
set the Status field to "partial success" and include the mobile set the Status field to "partial success" and include the mobile
node identifier, MN-ID, or the Home Network Prefix option to node identifier (MN-ID) or the Home Network Prefix option to
identify the binding(s) that failed to be removed as part of the identify the binding(s) that failed to be removed as part of the
revocation procedure. revocation procedure.
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 terminate the IPv6 or IPv4
setting the Home Network Prefix valid lifetime to zero. mobility session on the access link and notify the mobile node. The
specific details and considerations on how the mobile access gateway
terminates IPv6 or IPv4 mobility session on the access link and
notifies the mobile node can be found in [RFC5213] and [RFC5844].
After the mobile access gateway accepts or rejects a Binding After the mobile access gateway accepts or rejects a Binding
Revocation Indication message, the mobile access gateway MUST follow Revocation Indication message, the mobile access gateway MUST follow
Section 6.1 and Section 6.1.2 to send a Binding Revocation Sections 6.1 and 6.1.2 to send a Binding Revocation Acknowledgement
Acknowledgement message to the local mobility anchor. message to the local mobility anchor.
9.2. Sending Binding Revocation Indication 9.2. Sending Binding Revocation Indication
The mobile access gateway could send a Binding Revocation Indication The mobile access gateway could send a Binding Revocation Indication
message to indicate the termination of multiple mobile node bindings, message to indicate the termination of multiple mobile node bindings,
e.g., when using the global revocation with the Global (G) bit is e.g., when using the global revocation with the Global (G) bit set.
set. In this case when an event occurs which requires the mobile In this case, when an event occurs that requires the mobile access
access gateway to inform the local mobility anchor peer to terminate gateway to inform the local mobility anchor peer to terminate all
all mobile nodes bindings which are registered at the local mobility mobile node bindings that are registered at the local mobility anchor
anchor and the mobile access gateway, the mobile access gateway sends and the mobile access gateway, the mobile access gateway sends a
a Binding Revocation Indication message following the procedure in Binding Revocation Indication message following the procedure in
Section 6.1 and the followings: Section 6.1 and the following:
o The Proxy Binding (P) bit MUST be set to indicate that the o The Proxy Binding (P) bit MUST be set to indicate that the
binding(s) being revoked is a PMIPv6 binding. binding(s) 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 the mobile access gateway. In this case, the MN-ID option and the mobile access gateway. In this case, the MN-ID option
MUST be included in the Binding Revocation Indication and contain MUST be included in the Binding Revocation Indication and contain
the mobile access gateway identity. In addition, the mobile the mobile access gateway identity. In addition, the mobile
access gateway MAY include the Alternate Care-of Address option. access gateway MAY include the Alternate Care-of Address option.
If included, the Alternate Care-of Address option MUST contain the If included, the Alternate Care-of Address option MUST contain the
proxy Care-of address the bindings of which are being impacted by proxy care-of address the bindings that are being impacted by this
this Binding Revocation Indication message. 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.
As described in Section 6.3, the mobile access gateway SHOULD As described in Section 6.3, the mobile access gateway SHOULD
retransmit the Binding Revocation Indication to the local mobility retransmit the 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 node 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.
In a response to a Binding Revocation Indication message, if the In response to a Binding Revocation Indication message, if the mobile
mobile access gateway receives a packet carrying a Binding Revocation access gateway receives a packet carrying a Binding Revocation
Acknowledgement that was successfully processed as in Section 6.2 and Acknowledgement that was successfully processed as in Section 6.2 and
the Status field indicates (Global Revocation NOT Authorized), the the Status field indicates "Global Revocation NOT Authorized", the
mobile access gateway is not authorized to participate in a Per-Peer mobile access gateway is not authorized to participate in a Per-Peer
Global Revocation. The mobile access gateway SHOULD NOT retry Global Revocation. The mobile access gateway SHOULD NOT retry
sending a Binding Revocation Indication with the Global (G) bit is sending a Binding Revocation Indication with the Global (G) bit set
set and the Revocation Trigger field value is set to "Per-Peer and the Revocation Trigger field value set to "Per-Peer Policy" to
Policy" to the same local mobility agent. The mobile access gateway the same local mobility agent. The mobile access gateway should
should raise an alarm or log an event to indicate this rejection. raise an alarm or log an event to indicate this rejection.
10. Mobile Node Operation 10. Mobile Node Operation
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 6.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 tests List contains an entry for that Home Address. If one of the tests
fails, the mobile node SHOULD silently discard the received fails, the mobile node SHOULD silently discard the received
Binding Revocation Indication message. Binding Revocation Indication message.
o If mobile node Binding Update List contains an entry for the IP o If mobile node Binding Update List contains an entry for the IP
address in the Type 2 routing header of the received Binding address in the Type 2 routing header of the received Binding
Revocation Indication packet, the mobile node MUST accept the BRI Revocation Indication packet, the mobile node MUST accept the BRI
message using Status code success. message using status code "success".
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 ONLY release the Binding Revocation Indication as an indication to ONLY release the
mobile node IPv4 HoA binding 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 accept the IPv4 HoA binding. In this case, the mobile node MUST accept the
Binding Revocation Indication message using Status code success. Binding Revocation Indication message using status code "success".
On the other hand, if the IPv4 Home Address Option was NOT On the other hand, if the IPv4 Home Address Option was NOT
included in the received BRI with the (V) bit is set, the MN MUST included in the received BRI with the (V) bit is set, the MN MUST
reject the BRI message with Status code "IPv4 Home Address Option reject the BRI message with status code "IPv4 Home Address Option
Required". Additionally, if the IPv4 HoA received in the IPv4 Required". Additionally, if the IPv4 HoA received in the IPv4
Home Address Option is NOT the one assigned to the mobile node, Home Address Option is NOT the one assigned to the mobile node,
the mobile node SHOULD reject the Binding Revocation Indication the mobile node SHOULD reject the Binding Revocation Indication
with Status code "Binding Does NOT Exist". with status code "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 reject the Binding Revocation Indication using mobile node MUST reject the Binding Revocation Indication using
Status code "Proxy Binding Revocation NOT Supported". status code "Proxy Binding Revocation NOT Supported".
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 one or more BID options and its home
and its home address is included in the Type 2 routing header, the address is included in the Type 2 routing header, the mobile node
mobile node MUST consider all of the care-of address(es) MUST consider all of the care-of addresses bindings, identified in
binding(s), identified in the BID options, with this home address the BID options, with this home address as being revoked. In this
as being revoked. In this case, if the BRI validation is case, if the BRI validation is successful, the mobile node MUST
successful, the mobile node MUST accept the Binding Revocation accept the Binding Revocation Indication message with status code
Indication message with Status code success. "success".
o If the mobile node has multiple 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 as registered care-of address bindings with this home address as
being revoked. If the mobile node validates the BRI successfully, being revoked. If the mobile node validates the BRI successfully,
the mobile node MUST accept the Binding Revocation Indication the mobile node MUST accept the Binding Revocation Indication
message with Status code success. message with status code "success".
If the mobile node accepts or rejects the Binding Revocation If the mobile node accepts or rejects the Binding Revocation
Indication message, the mobile node MUST follow Section 6.1 and Indication message, the mobile node MUST follow Sections 6.1 and
Section 6.1.2 to send a Binding Revocation Acknowledgement message to 6.1.2 to send a Binding Revocation Acknowledgement message to the
the home agent. Note that anytime the MN does not send a Binding home agent. Note that anytime the MN does not send a Binding
Revocation Acknowledgement to a BRI, the initiator is likely to Revocation Acknowledgement to a BRI, the initiator is likely to
retransmit the BRI at least one time. This causes additional load on retransmit the BRI at least one time. This causes additional load on
the initiator who sends the retransmissions, as well as on the MN the initiator who sends the retransmissions, as well as on the MN
that will receive and process them. that will receive and process them.
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. Protocol Configuration Variables 11. Protocol Configuration Variables
Any mobility entity which is allowed to invoke the binding revocation Any mobility entity that 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.
The default value for this parameter is 1. The default value for this parameter is 1.
Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)
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 to be configured less than 0.5 The default is 1 second but is not to be configured to less than
seconds. 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.
12. 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 5. The new Mobility Header Type 16, as described in Section 5. The new
new Mobility Header type value needs to be assigned from the same 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. registry.
This document also creates a new registry "Binding Revocation Type" This document also creates a new registry "Binding Revocation Type"
which indicates the type of the binding revocation message. The that indicates the type of the binding revocation message. The
current binding revocation message types are described in Section 5.1 current binding revocation message types are described in Sections
and Section 5.2, and are the following: 5.1 and 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 unassigned
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 registry for the In addition, this document also creates a second new registry for the
Revocation Trigger which indicates the reason behind sending the Revocation Trigger that 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 5.1, and are the following: Trigger values are described in Section 5.1, and are the following:
Per-MN Revocation Trigger Values: Per-MN Revocation Trigger Values:
0 Unspecified 0 Unspecified
1 Administrative Reason 1 Administrative Reason
2 Inter-MAG Handover - same Access Type 2 Inter-MAG Handover - same Access Type
3 Inter-MAG Handover - different Access Type 3 Inter-MAG Handover - different Access Type
4 Inter-MAG Handover - Unknown 4 Inter-MAG Handover - Unknown
5 User Initiated Session(s) Termination 5 User-Initiated Session(s) Termination
6 Access Network Session(s) Termination 6 Access Network Session(s) Termination
7 Possible Out-of Sync BCE State 7 Possible Out-of-Sync BCE State
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
Reserved Revocation Trigger Values: Reserved Revocation Trigger Values:
250-255 Reserved For Testing Purposes only 250-255 Reserved For Testing Purposes only
All other values are Reserved All other values are Unassigned
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 registry "Status Code" Furthermore, this document creates a third new registry "Binding
for the Status field in the Binding Revocation Acknowledgement Revocation Acknowledgement Status Codes". The current values are
message. The current values are described in Section 5.2, and 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
135 Proxy Binding Revocation NOT Supported 135 Proxy Binding Revocation 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.
13. Security Considerations 13. Security Considerations
This specification allows the mobility node which initiates the This specification allows the mobility node that initiates the
binding revocation procedure to revoke mobility session(s) that is binding revocation procedure to revoke a mobility session(s) that is
currently registered with it. It is NOT allowed for any mobility currently registered with it. It is NOT allowed for any mobility
node to revoke a mobile node mobility session that is not registered node to revoke a mobile node mobility session that is not registered
with this mobility node. with this mobility node.
The binding revocation protocol described in this specification uses The binding revocation protocol described in this specification uses
the same security association between the mobile node and the home the same security association between the mobile node and the home
agent or the mobile access gateway and the local mobility anchor that agent or the mobile access gateway and the local mobility anchor that
is being used to exchange the MIPv6 or PMIPv6 Binding Update and is being used to exchange the MIPv6 or PMIPv6 Binding Update and
Binding Acknowledgement signaling. If IPsec is used, the traffic Binding Acknowledgement signaling. If IPsec is used, the traffic
selectors associated with the SPD entry protecting the Binding Update selectors associated with the Security Policy Database (SPD) entry
and Binding Acknowledgement MUST be extended to include Binding protecting the Binding Update and Binding Acknowledgement MUST be
Revocation Message MH type <IANA-TBD>. Extending the traffic extended to include Binding Revocation Message MH type 16. Extending
selectors of the SPD entry in order to reuse the SA protecting the the traffic selectors of the SPD entry in order to reuse the SA
Binding Update and Binding Acknowledgement (instead of creating new protecting the Binding Update and Binding Acknowledgement (instead of
ones) ensures that those SA will be up and running when the revoking creating new ones) ensures that those SAs will be up and running when
entity needs to send a binding revocation signaling message. the revoking entity needs to send a binding revocation signaling
message.
On the other hand, if IPsec is not used as the underlying security On the other hand, if IPsec is not used as the underlying security
mechanism to protect the Mobile IPv6 and its extensions binding mechanism to protect the Mobile IPv6 and its extensions binding
registration signaling, the used underlying security mechanism MUST registration signaling, the used underlying security mechanism MUST
provide protection against all identified security threats as provide protection against all identified security threats as
described under Security Considerations in [RFC3775] and [RFC5213]. described under "Security Considerations" in [RFC3775] and [RFC5213].
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 send and receive Binding Revocation access gateway, are allowed to send and receive Binding Revocation
Indication and Binding Revocation Acknowledgement for different Indications and Binding Revocation Acknowledgements for different
cases, therefore, when IPsec is used to secure signaling between the cases, when IPsec is used to secure signaling between the local
local mobility anchor and mobile access gateway, it prevents any of mobility anchor and mobile access gateway, it prevents any of them
them from processing a Binding Revocation Message that was not from processing a Binding Revocation Message that was not constructed
constructed by an authorized party. by an authorized party.
The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to The Proxy Mobile IPv6 [RFC5213] requires the local mobility anchor to
restrict the creation and manipulation of proxy bindings to restrict the creation and manipulation of proxy bindings to
specifically authorized mobile access gateways. Therefore, the specifically authorized mobile access gateways. Therefore, the
mobile access gateway which is authorized to create or manipulate the mobile access gateway that is authorized to create or manipulate the
mobile node proxy BCE is also authorized to revoke such mobile node mobile node proxy BCE is also authorized to revoke such mobile node
registration by sending a de-registration with lifetime of zero. registration by sending a de-registration with lifetime of zero.
However, since bulk termination using Binding Revocation Indication However, since bulk termination using Binding Revocation Indication
with the Global (G) bit set and the Revocation Trigger field set to with the Global (G) bit set and the Revocation Trigger field set to
"Per-Peer Policy" impacts all mobility sessions that are registered "Per-Peer Policy" impacts all mobility sessions that are registered
with the mobile access gateway and its local mobility anchor peer, with the mobile access gateway and its local mobility anchor peer,
the local mobility anchor MUST be locally configurable to authorize the local mobility anchor MUST be locally configurable to authorize
such specific functionality. Additional mechanisms, such as a policy such specific functionality. Additional mechanisms, such as a policy
store or Authentication, Authorization, and Accounting (AAA) may be store or Authentication, Authorization, and Accounting (AAA) may be
employed, but these are outside the scope of this specification. employed, but these are outside the scope of this specification.
14. Acknowledgements 14. Acknowledgements
skipping to change at page 38, line 4 skipping to change at page 37, line 19
the local mobility anchor MUST be locally configurable to authorize the local mobility anchor MUST be locally configurable to authorize
such specific functionality. Additional mechanisms, such as a policy such specific functionality. Additional mechanisms, such as a policy
store or Authentication, Authorization, and Accounting (AAA) may be store or Authentication, Authorization, and Accounting (AAA) may be
employed, but these are outside the scope of this specification. employed, but these are outside the scope of this specification.
14. Acknowledgements 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 document and all colleagues who have supported the advancement of
draft effort. this effort.
Also, we would like to thank Jari Arkko, Ben Campbell, Pasi Eronen, Also, we would like to thank Jari Arkko, Ben Campbell, Pasi Eronen,
Ralph Droms, Alexey Melnikov, Tim Polk, Adrian Farrel and Robert Ralph Droms, Alexey Melnikov, Tim Polk, Adrian Farrel, and Robert
Sparks for their reviews of this document as part of the IESG review Sparks for their reviews of this document as part of the IESG review
process. process.
15. References 15. References
15.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.
skipping to change at page 38, line 33 skipping to change at page 37, line 48
[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] [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
(work in progress), September 2009.
[RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration", and K. Nagami, "Multiple Care-of Addresses Registration",
RFC 5648, October 2009. RFC 5648, October 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.
15.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
Nortel Ericsson, Inc.
2221 Lakeside Blvd. 2201 Lakeside Blvd.
Richardson, TX 75082 Richardson, TX 75082
USA USA
Email: amuhanna@nortel.com EMail: ahmad.muhanna@ericsson.com
Mohamed Khalil Mohamed Khalil
Nortel Ericsson, Inc.
2221 Lakeside Blvd. 6300 Legacy Dr.
Richardson, TX 75082 Plano, TX 75024
USA USA
Email: mkhalil@nortel.com EMail: mohamed.khalil@ericsson.com
Sri Gundavelli Sri Gundavelli
Cisco Systems Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com EMail: sgundave@cisco.com
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Cisco
30 International Place 30 International Place
Tewksbury, MA 01876 Tewksbury, MA 01876
USA USA
Email: kchowdhury@starentnetworks.com EMail: kchowdhu@cisco.com
Parviz Yegani Parviz Yegani
Juniper Networks Juniper Networks
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: pyegani@juniper.net EMail: pyegani@juniper.net
 End of changes. 210 change blocks. 
484 lines changed or deleted 492 lines changed or added

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