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

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