draft-ietf-mext-binding-revocation-02.txt   draft-ietf-mext-binding-revocation-03.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: May 29, 2009 S. Gundavelli Expires: August 2, 2009 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
November 25, 2008 January 29, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-02.txt draft-ietf-mext-binding-revocation-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 29, 2009. This Internet-Draft will expire on August 2, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document defines the revocation semantics for terminating a This document defines the revocation semantics for terminating a
mobile node's mobility session and associated resources. These mobile node's mobility session and associated resources. These
semantics are generic enough and can be used by mobility entities in semantics are generic enough and can be used by mobility entities in
the case of Client Mobile IPv6 and its extensions. This mechanism the case of Client Mobile IPv6 and its extensions. This mechanism
allows the mobility entity which initiates the revocation procedure allows the mobility entity which initiates the revocation procedure
to request its corresponding one to terminate either one, multiple or to 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 24 skipping to change at page 2, line 30
2.1. Conventions used in this document . . . . . . . . . . . . 4 2.1. Conventions used in this document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4
3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5
3.2. Client MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . 6 3.2. Client MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . 6
3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7
3.3.1. Termination of Multiple Care-of Addresses Bindings . . 7 3.3.1. Termination of Multiple Care-of Addresses Bindings . . 7
3.3.2. Termination of All Care-of Addresses Bindings . . . . 8 3.3.2. Termination of All Care-of Addresses Bindings . . . . 8
3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8
3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8
3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 9 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 10
3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings . . 10 3.4.3. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10
4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Exchanging Binding Revocation Messages over an IPv4 5. Exchanging Binding Revocation Messages over an IPv4
Transport Network . . . . . . . . . . . . . . . . . . . . . . 10 Transport Network . . . . . . . . . . . . . . . . . . . . . . 10
6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11
6.1. Binding Revocation Indication Message . . . . . . . . . . 12 6.1. Binding Revocation Indication Message . . . . . . . . . . 12
6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 15
7. Binding Revocation Process Considerations . . . . . . . . . . 16 7. Binding Revocation Process Considerations . . . . . . . . . . 17
7.1. Sending Binding Revocation Messages . . . . . . . . . . . 16 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 17
7.2. Receiving Binding Revocation Messages . . . . . . . . . . 17 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 18
7.3. Retransmission of Binding Revocation Indication . . . . . 18 7.3. Retransmission of Binding Revocation Indication . . . . . 18
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 18 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19
8.1. Sending Binding Revocation Indication . . . . . . . . . . 18 8.1. Sending Binding Revocation Indication . . . . . . . . . . 19
8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20
9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 20 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 21
9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 20 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 21
9.1.1. Sending Binding Revocation Indication . . . . . . . . 20 9.1.1. Sending Binding Revocation Indication . . . . . . . . 21
9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 24
9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 23 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 24
9.2.1. Receiving Binding Revocation Indication . . . . . . . 23 9.2.1. Receiving Binding Revocation Indication . . . . . . . 24
9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 24 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 25
10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 25 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26
10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 25 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26
10.1.1. Receiving Binding Revocation Indication . . . . . . . 25 10.1.1. Receiving Binding Revocation Indication . . . . . . . 26
10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 27 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 28
10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 27 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 29
10.2.1. Sending Binding Revocation Indication . . . . . . . . 28 10.2.1. Sending Binding Revocation Indication . . . . . . . . 29
10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 28 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 30
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 29 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 30
11.1. Receiving Binding Revocation Indication . . . . . . . . . 29 11.1. Receiving Binding Revocation Indication . . . . . . . . . 30
11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 30 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 32
12. Protocol Configuration Variables . . . . . . . . . . . . . . . 31 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 32
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14. Security Considerations . . . . . . . . . . . . . . . . . . . 31 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 33
16.2. Informative References . . . . . . . . . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. Introduction 1. Introduction
In the case of Mobile IPv6 and for administrative reason, sometimes In the case of Mobile IPv6 and for administrative reason, sometimes
it becomes necessary to inform the mobile node that its registration it becomes necessary to inform the mobile node that its registration
has been revoked and the mobile node is no longer able to receive IP has been revoked and the mobile node is no longer able to receive IP
mobility service using its Home Address. In some networks where mobility service using its Home Address. In some networks where
Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4
registration revocation mechanism has been specified [RFC3543]. registration revocation mechanism has been specified [RFC3543].
skipping to change at page 5, line 11 skipping to change at page 5, line 11
node the termination of the mobile node registration binding. The node the termination of the mobile node registration binding. The
following subsections describe the protocol overview and applicable following subsections describe the protocol overview and applicable
use cases. use cases.
3.1. Binding Revocation Protocol 3.1. Binding Revocation Protocol
In the case of Client Mobile IPv6, the revocation procedure can be In the case of Client Mobile IPv6, the revocation procedure can be
initiated by the home agent. If the home network decides to initiated by the home agent. If the home network decides to
terminate the service of the mobile node, the home agent sends a terminate the service of the mobile node, the home agent sends a
Binding Revocation Indication (BRI) message to the mobile node. The Binding Revocation Indication (BRI) message to the mobile node. The
home agent includes the HoA option as specified in [RFC3775] to home agent includes the HoA in the type 2 routing header as specified
indicate the impacted mobile node binding. When the mobile node in [RFC3775] to indicate the impacted mobile node binding. When the
receives a BRI message with its HoA included and the Acknowledge (A) mobile node receives a BRI message with its HoA included and the
bit is set, the mobile node responds by sending a Binding Revocation Acknowledge (A) bit is set, the mobile node responds by sending a
Acknowledgement (BRA) message. Binding Revocation Acknowledgement (BRA) message.
In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also
be initiated by the home agent. If the home network decides to be initiated by the home agent. If the home network decides to
terminate the service of the mobile node, the home agent sends a BRI terminate the service of the mobile node, the home agent sends a BRI
message to the mobile node to indicate the termination of the mobile message to the mobile node to indicate the termination of the mobile
node IP Mobility service. The home agent may include the HoA option node IP Mobility service. The home agent may include the HoA option
with the mobile node assigned home IPv4 address. After receiving the with the mobile node assigned home IPv4 address. After receiving the
BRI message with the Acknowledge (A) bit is set, the mobile node BRI message with the Acknowledge (A) bit is set, the mobile node
responds by sending a BRA message. responds by sending a BRA message.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
indicate to the receiving node the cause for the revocation indicate to the receiving node the cause for the revocation
procedure. procedure.
3.2. Client MIPv6 and DSMIP6 Use Case 3.2. Client MIPv6 and DSMIP6 Use Case
Binding revocation mechanism is applicable to Client Mobile IPv6 and Binding revocation mechanism is applicable to Client Mobile IPv6 and
DSMIPv6 session(s) when the home agent needs to inform the mobile DSMIPv6 session(s) when the home agent needs to inform the mobile
node that its binding registration has been revoked, e.g. for an node that its binding registration has been revoked, e.g. for an
administrative reason. This mechanism enables the home domain to administrative reason. This mechanism enables the home domain to
dynamically allow the user to act upon the revocation message in dynamically allow the user to act upon the revocation message in
order to not have an unexpectedly interrupted mobile IPv6 services. order to recover its interrupted mobile IPv6 services.
In this case, the home agent sends a BRI message to indicate to the In this case, the home agent sends a BRI message to indicate to the
mobile node that its current mobile IPv6 binding has been revoked and mobile node that its current mobile IPv6 binding has been revoked and
it no longer can receive IP mobility service. The home agent it no longer can receive IP mobility service. The home agent
includes the mobile node home address in Type 2 header as used in includes the mobile node home address in Type 2 routing header as
[RFC3775] and sets the Revocation Trigger field to a proper value, used in [RFC3775] and sets the Revocation Trigger field to a proper
e.g. Administrative Reason. In the case of DSMIPv6 session, the value, e.g. Administrative Reason. In the case of DSMIPv6 session,
home agent may additionally include the mobile node assigned IPv4 the home agent may additionally include the mobile node assigned IPv4
Home Address Option. When the mobile node receives the BRI message, Home Address in the IPv4 Home Address Option. When the mobile node
it sends a BRA message as described in Section 11.2 to the home receives the BRI message, it sends a BRA message as described in
agent. Figure 1 illustrates the message sequencing when home agent Section 11.2 to the home agent. Figure 1 illustrates the message
revokes a mobile node binding registration. sequencing when home agent revokes a mobile node binding
registration.
MN HA MN HA
| | | |
| HoA in Type 2 Hdr + BRI [seq.#, A bit] | | HoA in Type 2 Hdr + BRI [seq.#, A bit] |
|<------------------------------------------| |<------------------------------------------|
| | | |
| | | |
| | | |
| HoA in Destination Option BRA[seq.#] | | HoA in Destination Option BRA[seq.#] |
|------------------------------------------>| |------------------------------------------>|
skipping to change at page 7, line 25 skipping to change at page 7, line 25
In the case of multiple care-of addresses, the home agent maintains In the case of multiple care-of addresses, the home agent maintains
different binding for each pair of care-of address and home address. different binding for each pair of care-of address and home address.
These bindings are also indexed and identified during the mobile node These bindings are also indexed and identified during the mobile node
registration using a Binding ID mobility option [ID-MCoA]. In this registration using a Binding ID mobility option [ID-MCoA]. In this
case, the HA may revoke any binding, more than one binding, or all of case, the HA may revoke any binding, more than one binding, or all of
the bindings for the same mobile node home address. the bindings for the same mobile node home address.
In the case when home agent revokes a single binding for a mobile In the case when home agent revokes a single binding for a mobile
node with multiple care-of addresses registration, the home agent node with multiple care-of addresses registration, the home agent
sends a BRI message to the mobile node with the corresponding BID sends a BRI message to the mobile node with the corresponding BID
option included and the HoA is in the Type 2 header. If the home option included and the HoA is in the Type 2 routing header. If the
agent needs to revoke more than one of the mobile node registered home agent needs to revoke more than one of the mobile node
care-of addresses, the home agent includes all the corresponding registered care-of addresses, the home agent includes all the
Binding ID options which reference these care-of addresses in the corresponding Binding ID options which reference these care-of
same BRI message. Figure 2 illustrates the message flow when the HA addresses in the same BRI message. Figure 2 illustrates the message
revokes two registered Care-of addresses for the same MN in a single flow when the HA revokes two registered Care-of addresses for the
BRI message. The home agent can revoke any registered binding(s) by same MN in a single BRI message. The home agent can revoke any
sending a BRI message to the respective mobile node. registered binding(s) by sending a BRI message to the respective
mobile node.
HA Binding Cache HA Binding Cache
================ ================
MN-BID1 [CoA1+HoA] MN-BID1 [CoA1+HoA]
MN HA MN-BID2 [CoA2+HoA] MN HA MN-BID2 [CoA2+HoA]
| | MN-BID3 [CoA3+HoA] | | MN-BID3 [CoA3+HoA]
| BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA] | BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA]
|<------------------------------------------| |<------------------------------------------|
| | | |
| | | |
skipping to change at page 8, line 28 skipping to change at page 8, line 29
the mobility entities, e.g. MAG and LMA, are always synchronized the mobility entities, e.g. MAG and LMA, are always synchronized
with respect to the status of the existing proxy mobile IPv6 with respect to the status of the existing proxy mobile IPv6
bindings. The binding revocation mechanism is generic enough that bindings. The binding revocation mechanism is generic enough that
can be used in all applicable PMIPv6 scenarios and deployment can be used in all applicable PMIPv6 scenarios and deployment
options. For example, this revocation mechanism is still applicable options. For example, this revocation mechanism is still applicable
and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports
and when the mobile node uses IPv4 or IPv6 address as specified in and when the mobile node uses IPv4 or IPv6 address as specified in
[ID-PMIP6-IPv4]. [ID-PMIP6-IPv4].
When the MAG receives a BRI message as in Section 10.1.1, the MAG When the MAG receives a BRI message as in Section 10.1.1, the MAG
sends a BRA message to the LMA following the rules describes in sends a BRA message to the LMA following the rules described in
Section 10.1.2. Similarly if the LMA receives a BRI message with the Section 10.1.2. Similarly if the LMA receives a BRI message with the
(A) bit is set, the LMA responds to the MAG by sending a BRA message. (A) bit is set, the LMA responds to the MAG by sending a BRA message.
3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding
The local mobility anchor may send a BRI message to the mobile access The local mobility anchor may send a BRI message to the mobile access
gateway, hosting a specific proxy mobile IPv6 binding, with the gateway, hosting a specific proxy mobile IPv6 binding, with the
appropriate value in the revocation trigger field to indicate that appropriate value in the revocation trigger field to indicate that
the mobile node binding has been terminated and the MAG can clean up the mobile node binding has been terminated and the MAG can clean up
the applicable resources. When the MAG receives a BRI message, the the applicable resources. When the MAG receives a BRI message, the
MAG identify the respected binding and if the (A) bit was set in the MAG identify the respected binding and if the (A) bit was set in the
received BRI message, the MAG sends a BRA message to the LMA. In received BRI message, the MAG sends a BRA message to the LMA. In
this case, the MAG could send a Router Advertisement message to the this case, the MAG could send a Router Advertisement message to the
MN with the home network prefix lifetime is set to zero. MN with the home network prefix lifetime set to zero.
As an example, Figure 3, illustrates the message sequence for As an example, Figure 3, illustrates the message sequence for
revoking a mobile node binding at the source MAG during the MN inter- revoking a mobile node binding at the source MAG during the MN inter-
MAG handoff. During the inter-MAG handoff, the mobile node moves MAG handoff. During the inter-MAG handoff, the mobile node moves
from the source MAG to the target MAG. The target MAG sends a PBU from the source MAG to the target MAG. The target MAG sends a PBU
with the new care-of-address to the LMA to update the mobile node with the new care-of-address to the LMA to update the mobile node
point of attachment. Since the MN binding at the LMA points to the point of attachment. Since the MN binding at the LMA points to the
source MAG and upon receiving the PBU from the target MAG, LMA source MAG and upon receiving the PBU from the target MAG, LMA
updates the MN BCE and send a PBA to the target MAG. LMA can send a updates the MN BCE and send a PBA to the target MAG. LMA can send a
BRI message with the appropriate revocation trigger value, e.g. BRI message with the appropriate revocation trigger value, e.g.
skipping to change at page 10, line 5 skipping to change at page 10, line 11
| | | | | |
Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff
3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings
The LMA sends a BRI message to indicate that all bindings which are The LMA sends a BRI message to indicate that all bindings which are
hosted by the peer MAG and registered with the LMA are being revoked hosted by the peer MAG and registered with the LMA are being revoked
by setting the (G) bit as described in Section 9.1.1. by setting the (G) bit as described in Section 9.1.1.
3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings 3.4.3. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings
The mobile access gateway sends a BRI message with the (G) bit is set The mobile access gateway sends a BRI message with the (G) bit is set
to indicate that all mobility bindings which are registered at the to indicate that all mobility bindings which are registered at the
LMA and attached to the MAG are being revoked as in Section 10.2.1. LMA and attached to the MAG are being revoked as in Section 10.2.1.
When the LMA receives a BRI message with the (G) bit is set from a When the LMA receives a BRI message with the (G) bit is set from a
specified MAG, the LMA checks if the MAG is authorized to use global specified MAG, the LMA checks if the MAG is authorized to use global
revocations and responds with the appropriate status code by sending revocations and responds with the appropriate status code by sending
a BRA message as in Section 9.2.2. a BRA message as in Section 9.2.2.
4. Security Model 4. Security Model
The binding revocation protocol described here uses the same security The binding revocation protocol described here uses the same security
association between the MN and the HA or the MAG and the LMA that has association between the MN and the HA or the MAG and the LMA that has
been used to exchange the corresponding Client MIPv6 or Proxy MIPv6 been used to exchange the corresponding Client MIPv6 or Proxy MIPv6
BU and BA when the mobile node binding was created. If IPsec is BU and BA when the mobile node binding was created. If IPsec is
used, the SPD of the respected IPsec SA MUST allow the Binding used, the traffic selectors associated with the SP protecting BU and
Revocation Signaling MH type <IANA-TBD> in order to allow BRI and BRA BA MUST be extended to include Binding Revocation Signaling MH type
messages to be exchanged. <IANA-TBD>. Extending the traffic selectors of the SP in order to
reuse the SA protecting BU and BA (instead of creating new ones)
ensures that those SA will be up and running when the revoking entity
needs to send a Binding Revocation Signaling message.
Additionally, in the case when the LMA receives a BRI which indicates Additionally, in the case when the LMA receives a BRI which indicates
a bulk termination, i.e., the (G) bit is set, the LMA MUST verify a bulk termination, i.e., the (G) bit is set, the LMA MUST verify
that the MAG sending the binding revocation indication message is that the MAG sending the binding revocation indication message is
authorized to invoke Global revocation. authorized to invoke Global revocation.
5. Exchanging Binding Revocation Messages over an IPv4 Transport 5. Exchanging Binding Revocation Messages over an IPv4 Transport
Network Network
In some deployments, the network between the MAG and the LMA may only In some deployments, the network between the MAG and the LMA may only
skipping to change at page 10, line 47 skipping to change at page 11, line 10
encapsulation to traverse NATs, then the Binding Revocation messages encapsulation to traverse NATs, then the Binding Revocation messages
are sent using the same UDP encapsulation. The same UDP port that are sent using the same UDP encapsulation. The same UDP port that
was used for the Proxy Binding Update and Proxy Binding was used for the Proxy Binding Update and Proxy Binding
Acknowledgement messages will also be used when transporting Binding Acknowledgement messages will also be used when transporting Binding
Revocation messages over IPv4 using UDP encapsulation. For more Revocation messages over IPv4 using UDP encapsulation. For more
details on tunneling Proxy Mobile IPv6 signaling messages over IPv4, details on tunneling Proxy Mobile IPv6 signaling messages over IPv4,
see [ID-PMIP6-IPv4]. see [ID-PMIP6-IPv4].
6. Binding Revocation Message 6. Binding Revocation Message
This section defines a Binding Revocation Message that use a MH type This section defines the Binding Revocation Message format using a MH
<IANA-TBD> with a Binding Revocation type field that follow the MH Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding
format described in section 6.1. [RFC3775]. The value in the Revocation Type field defines whether the Binding Revocation message
Binding Revocation Type field as shown in Figure 4 defines the type is a BRI or BRA. If the Binding Revocation type field is set to 1,
of the Binding Revocation message, (BRI or BRA). If the Binding the Binding Revocation Message is a Binding Revocation Indication
Revocation type field is set to 1, the Binding Revocation Message is message as in Section 6.1. However, if the value is 2, it is a
a Binding Revocation Indication message as in Section 6.1. However, Binding Revocation Acknowledgement message as in Section 6.2.
when the Binding Revocation type field is set to a value 2, the
Binding Revocation Message is a Binding Revocation Acknowledgement
message as in Section 6.2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Proto | Header Len | MH Type | Reserved | | Payload Proto | Header Len | MH Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | B.R. Type | | | Checksum | B.R. Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. Binding Revocation Message Data . . Binding Revocation Message Data .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Revocation Message Figure 4: Binding Revocation Message
Binding Revocation Type Binding Revocation Type
8-bit unsigned integer. It defines the type of Binding Revocation 8-bit unsigned integer. It defines the type of Binding Revocation
Message. It can be assigned one of the following values: Message. It can be assigned one of the following values:
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. It is either a BRI as value in the Binding Revocation Type field. It is either a BRI as
in Section 6.1 or BRA as in Section 6.2. in Section 6.1 or BRA as in 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
skipping to change at page 12, line 24 skipping to change at page 12, line 30
When the value 1 is indicated in the B. R. type field of the Binding When the value 1 is indicated in the B. R. type field of the Binding
Revocation Message, the format of the Binding Revocation Message Data Revocation Message, the format of the Binding Revocation Message Data
follows the Binding Revocation Indication message as in Figure 5 follows the Binding Revocation Indication message as in Figure 5
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 1 | R. Trigger | | B.R. Type = 1 | R. Trigger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |P|A|G| Reserved | | Sequence # |P|A|V|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Binding Revocation Indication Message Figure 5: Binding Revocation Indication Message
Revocation Trigger Revocation Trigger
8-bit unsigned integer indicting the event which triggered the 8-bit unsigned integer indicating the event which triggered the
revoking node to send the BRI message. The following Revocation revoking node to send the BRI message. The following Revocation
Trigger values are currently defined: Trigger values are currently defined:
0 Reserved. 0 Reserved
1 Unspecified. 1 Unspecified
2 Administrative Reason. 2 Administrative Reason
3 Inter-MAG Handoff - same Access Types. 3 Inter-MAG Handoff - same Access Types
4 Inter-MAG Handoff - different Access Types
4 Inter-MAG Handoff - different Access Types. 5 Inter-MAG - Unknown Handoff
5 Inter-MAG - Unknown Handoff. 6 Per-Peer Policy
6 Per-Peer Policy. 7 Revoking Node Local Policy
7 Revoking Node Local Policy. 8 User Initiated Session(s) Termination
8 User Initiated Session(s) Termination. 9 Access Network Session(s) Termination
9 Access Network Session(s) Termination. 10 IPv4 HoA Lease Expires
10 IPv4 HoA Binding ONLY. 11 Possible Out-of Sync BCE State
11 Possible Out-of Sync BCE State. 250-255 Reserved For Testing Purposes only
250-255 Reserved For Testing Purposes only. All other values are Reserved
All other values are Reserved.
Sequence # Sequence #
A 16-bit unsigned integer used by the sending mobility node to A 16-bit unsigned integer used by the sending mobility node to
match a returned Binding Revocation Acknowledgement with this match a returned Binding Revocation Acknowledgement with this
Binding Revocation Indication. Binding Revocation Indication.
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 proxy MIPv6 binding.
Acknowledge (A) Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobility node, e.g. The Acknowledge (A) bit is set by the sending mobility node, e.g.
LMA, HA, or MAG, to request a Binding Revocation Acknowledgement LMA, HA, or MAG, to request a Binding Revocation Acknowledgement
be returned upon receipt of the Binding Revocation Indication as be returned upon receipt of the Binding Revocation Indication as
in Section 8.1, Section 9.1.1, and Section 10.2.1. in Section 8.1, Section 9.1.1, and Section 10.2.1.
IPv4 HoA Binding Only (V)
The IPv4 HoA Binding Only (V) bit is set by the sending mobility
node, HA or LMA, to request the receiving mobility entity the
termination of the IPv4 Home Address binding only as in
Section 8.1, and Section 9.1.1.
Global (G) 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 26 skipping to change at page 14, line 38
when the (P) bit is set. Additionally, If the (G) bit is set by when the (P) bit is set. Additionally, If the (G) bit is set by
the mobile access gateway, this option carries the MAG identity. the mobile access gateway, this option carries the MAG identity.
o Binding ID mobility option [ID-MCoA]. This option is mandatory if o Binding ID mobility option [ID-MCoA]. This option is mandatory if
the sending mobility entity request to terminate one binding of a the sending mobility entity request to terminate one binding of a
multi care-of addresses bindings for the same mobile node. The multi care-of addresses bindings for the same mobile node. The
sending mobility entity may include more than one of the Binding sending mobility entity may include more than one of the Binding
ID mobility options. ID mobility options.
o IPv4 Home Address option which contains the mobile node home IPv4 o IPv4 Home Address option which contains the mobile node home IPv4
address [ID-DSMIP6]. address [ID-DSMIP6]. This option is included only when the IPv4
HoA Binding only (V) bit is set.
o Alternate Care-of Address mobility option [RFC3775]. This option
MAY be included to indicate the Care-of Address of the mobile
node's binding that is being revoked. In the case when the Global
(G) bit set, this option identifies all the mobility bindings that
share the same care-of address. Additionally, if the Global (G)
bit set, more than one Alternate Care-of Address mobility options
MAY be present in the BRI message.
If no options are present in this message, 4 octets of padding are 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 4 skipping to change at page 15, line 18
Revocation Message which has a MH type <IANA-TBD> and a Binding Revocation Message which has a MH type <IANA-TBD> and a Binding
Revocation Type value of 2. It is used to acknowledge the receipt of Revocation Type value of 2. It is used to acknowledge the receipt of
a Binding Revocation Indication message described in Section 6.1. a Binding Revocation Indication message described in Section 6.1.
This packet is sent as described in Section 9.2.2, Section 10.1.2, This packet is sent as described in Section 9.2.2, Section 10.1.2,
and Section 11.2. and Section 11.2.
When the value 2 is indicated in the Binding Revocation type field of When the value 2 is indicated in the Binding Revocation type field of
the Binding Revocation Message, the format of the Binding Revocation the Binding Revocation Message, the format of the Binding Revocation
Message Data follows the Binding Revocation Acknowledgement message Message Data follows the Binding Revocation Acknowledgement message
as in Figure 6 as in Figure 6
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 2 | Status | | B.R. Type = 2 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |P|G| Reserved | | Sequence # |P|V|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Binding Revocation Acknowledgement Message Figure 6: Binding Revocation Acknowledgement Message
Status Status
8-bit unsigned integer indicating the result of processing the 8-bit unsigned integer indicating the result of processing the
Binding Revocation Indication message by the receiving mobility Binding Revocation Indication message by the receiving mobility
entity. The following status values are currently defined. entity. The following status values are currently defined.
0 success. 0 success
1 partial success. 1 partial success
2 Binding Does NOT Exist. 128 Binding Does NOT Exist
3 IPv4 HoA Binding Does NOT Exist. 129 IPv4 HoA Binding Does NOT Exist
4 Global Revocation NOT Authorized. 130 IPv4 HoA Option Required
5 CAN NOT Identify Binding. 131 Global Revocation NOT Authorized
6 Revocation Failed, MN is Attached. 132 CAN NOT Identify Binding
133 Revocation Failed, MN is Attached
Sequence # Sequence #
The sequence number in the Binding Revocation Acknowledgement is The sequence number in the Binding Revocation Acknowledgement is
copied from the Sequence Number field in the Binding Revocation copied from the Sequence Number field in the Binding Revocation
Indication. It is used by the revoking mobility entity, e.g. HA, Indication. It is used by the revoking mobility entity, e.g. HA,
LMA, in matching this Binding Revocation Acknowledgement with the LMA, in matching this Binding Revocation Acknowledgement with the
outstanding BRI. outstanding BRI.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set if the (P) bit is set in the The Proxy Binding (P) bit is set if the (P) bit is set in the
corresponding Binding Revocation Indication message. corresponding Binding Revocation Indication message.
IPv4 HoA Binding Only (V)
The IPv4 HoA Binding Only (V) bit is set if the (V) bit is set in
the corresponding BRI 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. Section 9.2.2 and Section 10.1.2. corresponding BRI message.
Reserved Reserved
These fields are unused. They MUST be initialized to zero by the These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
skipping to change at page 19, line 12 skipping to change at page 19, line 35
mobile node to send a Binding Revocation Acknowledgement upon mobile node to send a Binding Revocation Acknowledgement upon
receipt of the BRI. receipt of the BRI.
o The Revocation Trigger field MUST be set in the Binding Revocation o The Revocation Trigger field MUST be set in the Binding Revocation
Indication to indicate to the mobile node the reason for revoking Indication to indicate to the mobile node the reason for revoking
its IP mobility binding with the home agent. The Revocation its IP mobility binding with the home agent. The Revocation
Trigger may be used by the mobile node to take further steps if Trigger may be used by the mobile node to take further steps if
necessary. necessary.
o The Binding Revocation Indication MUST be sent using a type 2 o The Binding Revocation Indication MUST be sent using a type 2
routing header which contains the mobile node's registered home routing header which contains the mobile node's registered IPv6
address for the binding being revoked. home address for the binding being revoked.
o The care-of address for the binding MUST be used as the o The care-of address for the binding MUST be used as the
destination address in the packet's IPv6 header, unless an destination address in the packet's IPv6 header, unless an
Alternate Care-of Address mobility option is included in the Alternate Care-of Address mobility option is included in the
Binding Revocation Indication. Binding Revocation Indication.
o The packet MAY contain an IPv4 Home Address option which contains o If the home agent needs to only revoke the mobile node's IPv4 home
the mobile node's registered IPv4 home address for the binding address binding, the home agent MUST set the IPv4 HoA Binding Only
being revoked. (V) bit and MUST include the mobile node's registered IPv4 home
address that is being revoked in the IPv4 Home Address option.
The Acknowledge (A) bit in the Binding Revocation Indication requests The 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 send a BRI to the mobile node with the (A) bit is When the home agent sends a BRI to the mobile node with the (A) bit
set, the home agent sets a flag in the mobile node BCE to indicate set, the home agent sets a flag in the mobile node BCE to indicate
that revocation is in progress and starts the MINDelayBRIs timer. that revocation is in progress and starts the MINDelayBRIs timer.
The home agent maintains the mobile node BCE in this state until it The home agent maintains the mobile node BCE in this state until it
receives a Binding Revocation Acknowledgement or the receives a Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached. BRIMaxRetransmitNumber is reached.
In a race condition case, the home agent may receive a BU from the
mobile node while the mobile node's BCE has the revocation in
progress flag set, the home agent should handle this case based on
the reason for sending the Binding Revocation Indication message and
its local policy. In this case, if the home agent accepts the BU, it
needs to update the mobile node BCE accordingly, e.g. removing the
revocation in progress flag.
When the home agent needs to revoke one or more of a mobile node When the home agent needs to revoke one or more of a mobile node
bindings that were created using Multi Care-of address registration bindings that were created using Multi Care-of address registration
as in [ID-MCoA], the home agent MUST include all the related Binding as in [ID-MCoA], the home agent MUST include all the related Binding
ID options that identify these bindings in the Binding Revocation ID options that identify these bindings in the Binding Revocation
Indication message. In the case when the home agent needs to revoke Indication message. In the case when the home agent needs to revoke
all of the mobile node bindings, the home agent MUST NOT include any all of the mobile node bindings, the home agent MUST NOT include any
of the Binding ID options. of the Binding ID options.
The home agent MUST use the IPsec security association that has been The home agent MUST use the IPsec security association that has been
used during the MIPv6 binding registration with the HA to secure the used during the MIPv6 binding registration with the HA to secure the
skipping to change at page 20, line 31 skipping to change at page 21, line 15
9. Local Mobility Anchor Operation 9. Local Mobility Anchor Operation
9.1. Binding Revocation Initiator 9.1. Binding Revocation Initiator
9.1.1. Sending Binding Revocation Indication 9.1.1. Sending Binding Revocation Indication
When an event requires the local mobility agent to terminate a mobile When an event requires the local mobility agent to terminate a mobile
node proxy mobile IPv6 registration, e.g. for administrative reason node proxy mobile IPv6 registration, e.g. for administrative reason
or inter-MAG handover, the local mobility agent sends a Binding or inter-MAG handover, the local mobility agent sends a Binding
Revocation Indication message to the mobile access gateway which host Revocation Indication message to the mobile access gateway which host
the mobile node proxy CoA to indicate that the mobile node specified the mobile node proxy CoA to indicate that the mobile node's
binding should be removed. It also indicate that the LMA will no specified binding should be removed. It also indicate that the LMA
longer maintain a tunnel for this mobile node binding which points to will no longer maintain a tunnel for this mobile node binding which
the mobile node proxy CoA that is hosted at this MAG. points to the mobile node proxy CoA that is hosted at this MAG.
To terminate a mobile node proxy mobile IPv6 registration and its To terminate a mobile node proxy mobile IPv6 registration and its
current PMIPv6 binding with the local mobility agent, the LMA sends a current PMIPv6 binding with the local mobility agent, the LMA sends a
packet to the MAG containing a BRI message following the procedure in packet to the MAG containing a BRI message following the procedure in
Section 7.1 and the following rules: Section 7.1 and the following rules:
o The Acknowledge (A) bit MAY be set in the Binding Revocation o The Acknowledge (A) bit MAY be set in the Binding Revocation
Indication to request the mobile access gateway to send a Binding Indication to request the mobile access gateway to send a Binding
Revocation Acknowledgement upon receipt of the BRI. Revocation Acknowledgement upon receipt of the BRI.
o The Proxy Mobile IP (P) bit MUST be set in the BRI message to o The Proxy Mobile IP (P) bit MUST be set in the BRI message to
indicate that the binding being revoked is a proxy Mobile IPv6 indicate that the binding being revoked is a proxy Mobile IPv6
binding. binding.
o The Revocation Trigger field MUST be set in the Binding Revocation o The Revocation Trigger field MUST be set in the Binding Revocation
Indication to indicate to the mobile access gateway the reason for Indication to indicate to the mobile access gateway the reason for
removing the specified mobile node proxy mobile IPv6 binding at removing the specified mobile node proxy mobile IPv6 binding at
the LMA. The Revocation Trigger may be used by the mobile access the LMA. The Revocation Trigger may be used by the mobile access
gateway node to learn the mobile node latest movement. gateway to learn the 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" in the Binding Revocation Indication to request the
mobile access gateway to remove all Per-Peer bindings that are mobile access gateway to remove all Per-Peer bindings that are
registered with the LMA and hosted at this MAG. registered with the LMA and hosted at this MAG.
o Whenever the Global (G) bit is set in the BRI, the Acknowledge (A) o Whenever the Global (G) bit is set in the BRI, the Acknowledge (A)
bit MUST be set to request the mobile access gateway to send a bit MUST be set to request the mobile access gateway to send a
Binding Revocation Acknowledgement upon receipt of the BRI. Binding Revocation Acknowledgement upon receipt of the BRI.
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 The packet MUST contain a Home Network Prefix option, which o If the Mobile Node Identifier, MN-ID, is registered in more than
one of the mobile node's BCE and the LMA does NOT need to revoke
all of the mobile node's bindings, the packet MUST contain another
identifier to uniquely identify the mobile node binding(s) that is
being revoked, e.g., at least one Home Network Prefix option which
contains the mobile node's registered HNP for the binding being contains the mobile node's registered HNP for the binding being
revoked. revoked.
o The care-of address for the binding MAY be used as the destination o The care-of address for the binding MAY be used as the destination
address in the packet's IPv6 header, unless an Alternate Care-of address in the packet's IPv6 header, unless an Alternate Care-of
Address mobility option is included in the Binding Revocation Address mobility option is included in the Binding Revocation
Indication message. 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 in response to this Binding Revocation Indication.
As described in Section 7.3, the LMA SHOULD retransmit this BRI to As described in Section 7.3, the LMA SHOULD retransmit this BRI to
the MAG before deleting the mobile node IP tunnel to the mobile the MAG before deleting the mobile node IP tunnel to the mobile
access gateway until it receives a matching Binding Revocation access gateway until it receives a matching Binding Revocation
Acknowledgement or the BRIMaxRetransmitNumber is reached. The local Acknowledgement or the BRIMaxRetransmitNumber is reached. The local
mobility anchor MAY delete the mobile node(s) IP tunnel immediately mobility anchor MAY delete the mobile node(s) IP tunnel immediately
after sending the Binding Revocation Indication and before receiving after sending the Binding Revocation Indication and before receiving
the BRA message. the BRA message.
When the local mobility anchor sends a Binding Revocation Indication When the local mobility anchor sends a Binding Revocation Indication
to the mobile access gateway to remove a specific binding, the local to the mobile access gateway to remove a specific binding and the
mobility anchor sets a flag in the mobile node proxy BCE to indicate Acknowledge (A) bit is set in the BRI, the local mobility anchor sets
that revocation is in progress and starts the MINDelayBRIs timer. a flag in the mobile node proxy BCE to indicate that revocation is in
The local mobility anchor SHOULD maintain the mobile node proxy BCE progress and starts the MINDelayBRIs timer. The local mobility
in this state until it receives a Binding Revocation Acknowledgement anchor SHOULD maintain the mobile node proxy BCE in this state until
or the BRIMaxRetransmitNumber is reached. In the case when the local it receives a Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached. In the case when the local
mobility anchor sets the Revocation Trigger field to a value which mobility anchor sets the Revocation Trigger field to a value which
indicate inter-MAG handover, the local mobility anchor MAY switch the indicate inter-MAG handover, the local mobility anchor MAY switch the
mobile node IP tunnel to the target mobile access gateway before mobile node IP tunnel to the target mobile access gateway before
sending a Binding Revocation Indication to the sources mobile access sending a Binding Revocation Indication to the sources mobile access
gateway. gateway.
In a race condition case, the local mobility anchor may receive a PBU
from the mobile access gateway while the mobile node's proxy BCE has
the revocation in progress flag set, the LMA should handle this case
based on the reason for sending the Binding Revocation Indication
message and its local policy. In this case, if the LMA accepts the
PBU, it needs to update the mobile node proxy BCE accordingly, e.g.
removing the revocation in progress flag.
When the local mobility anchor needs to revoke all mobile nodes proxy When the local mobility anchor needs to revoke all mobile nodes proxy
BCE that are registered with the local mobility anchor and hosted at BCE that are registered with the local mobility anchor and hosted at
the mobile access gateway, the LMA MUST set the Global (G) bit and the mobile access gateway, the LMA MUST set the Global (G) bit and
the value of the Revocation Trigger field to "Per-Peer Policy". In the value of the Revocation Trigger field to "Per-Peer Policy". In
this case, the LMA MUST NOT include any mobility options in the BRI. this case, the LMA MUST NOT include any mobility options in the BRI.
When the LMA needs to revoke all mobile nodes proxy BCE that belong When the LMA needs to revoke all mobile nodes proxy BCE that belong
to a specific realm, e.g. @companyabc.com, and are registered with to a specific realm, e.g. @companyabc.com, and are registered with
the LMA and hosted at the MAG, the local mobility anchor MUST set the the LMA and hosted at the MAG, the local mobility anchor MUST set the
Global (G) bit and the value of the Revocation Trigger field to Global (G) bit and the value of the Revocation Trigger field to
skipping to change at page 22, line 47 skipping to change at page 23, line 40
revoke the mobile node IPv4 proxy HoA binding to the current mobile revoke the mobile node IPv4 proxy HoA binding to the current mobile
node proxy CoA while maintaining the mobile node binding of the HNP node proxy CoA while maintaining the mobile node binding of the HNP
to its current pCoA as part of the mobile node BCE. In this case, if to its current pCoA as part of the mobile node BCE. In this case, if
the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the
LMA MUST send a BRI message following the procedure in Section 7.1 LMA MUST send a BRI message following the procedure in Section 7.1
and the following rules: and the following rules:
o The Acknowledge (A) bit MUST be set in the BRI to request the MAG o The Acknowledge (A) bit MUST be set in the BRI to request the MAG
to send a BRA message. to send a BRA message.
o The Revocation Trigger field MUST be set to "IPv4 HoA Binding o The IPv4 HoA Binding Only (V) bit MUST be set in the BRI to
ONLY". indicate that only the IPv4 home address binding is being revoked.
o The IPv4 Home Address option MUST be included with the mobile node o The IPv4 Home Address option MUST be included with the mobile
IPv4 home address that to be released in addition to the MN-ID node's registered IPv4 home address that is being released in
option. addition to the MN-ID option.
o The mobile node HNP 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,
e.g. "IPv4 Address Lease Expired".
9.1.2. Receiving Binding Revocation Acknowledgement 9.1.2. Receiving Binding Revocation Acknowledgement
When the local mobility anchor receives a packet carrying a valid When the local mobility anchor receives a packet carrying a valid
Binding Revocation Acknowledgement that was successfully processed as Binding Revocation Acknowledgement that was successfully processed as
in Section 7.2 and if the mobile node BCE is in the state of in Section 7.2 and if the mobile node BCE is in the state of
Revocation in progress, the local mobility anchor SHOULD examine the Revocation in progress, the local mobility anchor SHOULD examine the
Status field before clearing the mobile node related resources as Status field before clearing the mobile node related resources as
follows: follows:
skipping to change at page 23, line 48 skipping to change at page 24, line 42
When the local mobility anchor receives a packet carrying a Binding When the local mobility anchor receives a packet carrying a Binding
Revocation Indication that was successfully processed as in Revocation Indication that was successfully processed as in
Section 7.2, the local mobility anchor SHOULD in addition process the Section 7.2, the local mobility anchor SHOULD in addition process the
message as follows: message as follows:
o Binding Revocation Indication is formatted as in Section 6.1 and o Binding Revocation Indication is formatted as in Section 6.1 and
if the (P) bit is set, the local mobility anchor MUST validate if the (P) bit is set, the local mobility anchor MUST validate
that all impacted binding(s) have the proxy binding flag set. that all impacted binding(s) have the proxy binding flag set.
o If the Global (G) bit is set, the BRI SHOULD contain the mobile o If the Global (G) bit is set, the Proxy (P) bit MUST be set and
access gateway ID in the MN-ID option. The local mobility anchor the BRI SHOULD contain the mobile access gateway ID in the MN-ID
MUST verify that the identified mobile access gateway as per the option. The local mobility anchor MUST verify that the identified
value in the MN-ID option is authorized to use the Per-Peer Global mobile access gateway as per the value in the MN-ID option is
bindings revocation. The mechanism the LMA uses to verify the MAG authorized to use the Per-Peer Global bindings revocation. The
authorization is out of scope of this document. When the (P) bit mechanism the LMA uses to verify the MAG authorization is out of
is set, this Binding Revocation Indication impact only the mobile scope of this document.
nodes bindings that have the Proxy Mobile IP flag set.
o The LMA identify all impacted mobile nodes bindings and if the o If the Global (G) bit is set and only the mobile node identifier,
MN-ID, option is included, the local mobility anchor MUST revoke
all mobile nodes bindings which proxy CoA is the one used as the
source of the IPv6 packet that carried the BRI. However, if one
or more Alternate Care-of Address options are included in addition
to the mobile node identifier option in the BRI message, the local
mobility anchor MUST revoke all mobile nodes bindings which proxy
Care-of Address is one of the Care-of.
o The LMA identifies all impacted mobile nodes bindings and if the
Acknowledgement (A) bit is set, the local mobility anchor MUST Acknowledgement (A) bit is set, the local mobility anchor MUST
send a Binding Revocation Acknowledgement following Section 9.2.2 send a Binding Revocation Acknowledgement following Section 9.2.2
using the appropriate status code. using the appropriate status code.
o If the Global (G) bit is not set, the local mobility anchor MUST o If the Global (G) bit is NOT set, the local mobility anchor MUST
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 have a proxy CoA that is used as the source mobile node which use the specified mobile node NAI.
of the IPv6 packet that carried the BRI or in the Alternate
Care-of-Address option in the BRI.
2. If the mobile node identifier, MN-ID, and the Home Network 2. If the mobile node identifier, MN-ID, and the Home Network
Prefix option are included, the local mobility anchor MUST Prefix option are included, the local mobility anchor MUST
only remove the specified proxy binding. only remove the specified proxy binding.
3. If the mobile node identifier, MN-ID, option and more than one 3. If the mobile node identifier, MN-ID, option and more than one
Home Network Prefix options are included, the local mobility Home Network Prefix options are included, the local mobility
anchor MUST remove all bindings which are referenced by these anchor MUST remove all bindings which are referenced by these
multiple Home Network Prefixes for the specified mobile node multiple Home Network Prefixes for the specified mobile node
NAI. In case that these Home Network Prefixes are all the NAI.
allocated Home Network Prefixes for the mobile node BCE, the
LMA needs to remove the mobile node BCE.
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 is set and after processing the BRI Indication with the (A) bit set and after processing the BRI message,
message, the local mobility anchor sends a packet to the mobile the local mobility anchor sends a packet to the mobile access gateway
access gateway containing a Binding Revocation Acknowledgement containing a Binding Revocation Acknowledgement following the process
following the process in Section 7.1 and the following: 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. BRA.
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 BRI, the local
mobility anchor MUST set the (G) bit in the Binding Revocation mobility anchor MUST set the (G) bit in the Binding Revocation
Acknowledgement. Acknowledgement.
o If the IPv4 HoA Binding Only (V) bit was set in the received BRI,
the local mobility anchor MUST set the (V) bit in the Binding
Revocation Acknowledgement.
o The local mobility anchor MUST set the status field to a valid 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 LMA
MUST set the status field to (Global Revocation NOT Authorized). MUST set the status field to (Global Revocation NOT Authorized).
o The LMA MAY set the status field to partial success and in this o In the case that one of the bindings identified in the received
BRI message has already been released before receiving the BRI,
the LMA MAY set the status field to partial success and in this
case it MAY include the mobile node identifier or the Home Network case it MAY include the mobile node identifier or the Home Network
Prefix option to identify the binding(s) that failed revocation. 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 BRI.
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 if the (P) bit is set, o BRI MUST be formatted as in Section 6.1 and the (P) bit is set.
the mobile access gateway must validate that the impacted binding
have the proxy binding flag set.
o If the Acknowledgement (A) bit in the received BRI is set, the o If the Acknowledgement (A) bit in the received BRI is set, the
mobile access gateway MUST send a Binding Revocation mobile access gateway MUST send a Binding Revocation
Acknowledgement following Section 10.1.2 using the appropriate Acknowledgement following Section 10.1.2 using the appropriate
status value. status value.
o If the Global (G) bit is set and the Revocation Trigger field is o If the Global (G) bit is set and the Revocation Trigger field is
set to "Per-Peer policy", the mobile access gateway identify all set to "Per-Peer policy", the mobile access gateway identifies all
bindings that are registered at the LMA and hosted at the MAG. bindings that are registered at the LMA and hosted at the MAG.
This Binding Revocation Indication does not include any other This Binding Revocation Indication does not include any other
mobility options. However, if the (P) bit is set, this BRI MUST mobility options. In this case, the MAG MUST send a BRA with the
only impact mobile nodes bindings that have the Proxy Mobile IP
flag set. In this case, the MAG MUST send a BRA with the
appropriate status code to the LMA. appropriate status code to the LMA.
o If the Global (G) bit is set and the Revocation Trigger field is o If the Global (G) bit is set and the Revocation Trigger field is
set to "Revoking Node Local Policy", the MAG MUST identify all set to "Revoking Node Local Policy", the MAG MUST identify all
bindings that are registered at the LMA and hosted at the MAG bindings that are registered at the LMA and hosted at the MAG
using the mobility option(s) included in the BRI. This Binding using the mobility option(s) included in the BRI. This Binding
Revocation Indication SHOULD include at least the MN-ID option, Revocation Indication SHOULD include at least the MN-ID option,
e.g. with a wild card NAI. In this case, the MAG MUST send a BRA e.g. with a wild card NAI. In this case, the MAG MUST send a BRA
with the appropriate status code to the LMA. with the appropriate status code to the LMA.
skipping to change at page 26, line 33 skipping to change at page 27, line 37
Binding". Binding".
o If the Revocation Trigger field value in the received Binding o If the Revocation Trigger field value in the received Binding
Revocation Indication message indicates an inter-MAG handover and Revocation Indication message indicates an inter-MAG handover and
the (A) bit is set, the MAG use the mobility option(s) included in the (A) bit is set, the MAG use the mobility option(s) included in
the BRI message to identify the mobile node binding. The mobile the BRI message to identify the mobile node binding. The mobile
access gateway MAY validate that the mobile node is no longer access gateway MAY validate that the mobile node is no longer
attached to the mobile access gateway before sending a successful attached to the mobile access gateway before sending a successful
Binding Revocation Acknowledgement message to the LMA. However, Binding Revocation Acknowledgement message to the LMA. However,
if the Revocation Trigger field is set to "Inter-MAG - Unknown if the Revocation Trigger field is set to "Inter-MAG - Unknown
Handoff", the MAG MUST validate that the mobile node is no longer Handoff" and the (A) bit is set, the MAG MUST validate that the
attached to the MAG before sending a successful BRA message and mobile node is no longer attached to the MAG before sending a
deleting the resources associated with the mobile node binding. successful BRA message and deleting the resources associated with
the mobile node binding. Otherwise, if the MAG verified that the
MN is still attached, the MAG MUST set the status field in the BRA
to "Revocation failed - MN is attached".
o If the Revocation Trigger field in the received BRI message is set o If the IPv4 HoA Binding Only (V) bit in the received BRI message
to "IPv4 HoA Binding ONLY", the MAG uses the MN-ID option to is set, the MAG uses the MN-ID option to identify the mobile node
identify the mobile node binding entry in the BUL. The MAG MUST binding entry in the BUL. The MAG MUST verify that the IPv4
verify that the IPv4 address included in the IPv4 Home Address address included in the IPv4 Home Address option in the received
option in the received BRI is the same as the IPv4 proxy HoA that BRI is the same as the IPv4 proxy HoA that is assigned to the
is assigned to the mobile node. After the MAG successfully mobile node. After the MAG successfully validates the received
validate the received IPv4 home address as the mobile node IPv4 IPv4 home address as the mobile node IPv4 HoA, the MAG MUST
HoA, the MAG MUST consider this as an indication to release the consider this as an indication to release the mobile node IPv4
mobile node IPv4 proxy HoA binding to the mobile node current proxy HoA binding to the mobile node current proxy CoA ONLY.
proxy CoA ONLY. Consequently, the MAG MUST continue to maintain
the mobile node IPv6 proxy HoA or HNP binding to the current Consequently, the MAG MUST continue to maintain the mobile node
mobile node proxy CoA as part of the mobile node binding in the IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA
BUL entry and release all resources associated with the MN IPv4 as part of the mobile node binding in the BUL entry and release
proxy HoA binding to the MN pCoA. In this case, the MAG MUST send all resources associated with the MN IPv4 proxy HoA binding to the
a BRA message with the status field is set to success. On the MN pCoA. In this case, the MAG MUST send a BRA message with the
other hand, if the MAG is able to identify the mobile node binding status field is set to success. On the other hand, if the MAG is
using the MN-ID but failed to identify the received IPv4 proxy able to identify the mobile node binding using the MN-ID but
HoA, the MAG MUST send a BRA with status field is set to "IPv4 HoA failed to identify the received IPv4 proxy HoA, the MAG MUST send
Binding Does NOT Exist". a BRA with status field is set to "IPv4 HoA Binding Does NOT
Exist".
The Revocation Trigger field value in the received BRI could be used The Revocation Trigger field value in the received BRI could be used
by the mobile access gateway to define what actions the MAG could do by the mobile access gateway to define what actions the MAG could do
to inform the mobile node that its IP connectivity to the current HNP to inform the mobile node that its IP connectivity to the current HNP
has been terminated. e.g. if the Revocation Trigger field is set to has been terminated. e.g. if the Revocation Trigger field is set to
"Administrative Reason", the mobile access gateway may send a RA "Administrative Reason", the mobile access gateway may send a RA
message after setting the Home Network Prefix lifetime to zero. message after setting the Home Network Prefix lifetime to zero.
10.1.2. Sending Binding Revocation Acknowledgement 10.1.2. Sending Binding Revocation Acknowledgement
When the mobile access gateway receive a valid Binding Revocation When the mobile access gateway receive a valid Binding Revocation
Indication with the (A) bit is set and after processing the BRI Indication with the (A) bit set and after processing the BRI message,
message, the mobile access gateway sends a packet to the local the mobile access gateway sends a packet to the local mobility anchor
mobility anchor containing a Binding Revocation Acknowledgement containing a Binding Revocation Acknowledgement according to the
according to the procedure in Section 7.1 and the following: procedure in 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 BRI.
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 BRI, the mobile
access gateway MUST set the (G) bit in the Binding Revocation access gateway MUST set the (G) bit in the Binding Revocation
Acknowledgement. Acknowledgement.
o If the IPv4 HoA Binding Only (V) bit was set in the received BRI,
the mobile access gateway MUST set the (V) bit in the Binding
Revocation Acknowledgement.
o The mobile access gateway MUST set the status field to a valid 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 The mobile access gateway MAY set the status field to partial o In the case that one or more of the bindings identified in the
success and in this case it MAY include the mobile node received BRI message has already been released before receiving
the BRI, the mobile access gateway MAY set the status field to
partial success and in this case it MAY include the mobile node
identifier, MN-ID, or the Home Network Prefix option to identify identifier, MN-ID, or the Home Network Prefix option to identify
the binding(s) that failed to be removed as part of the revocation the binding(s) that failed to be removed as part of the revocation
procedure. 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
skipping to change at page 28, line 30 skipping to change at page 29, line 36
o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation
Indication to indicate that bindings that being revoked is a proxy Indication to indicate that bindings that being revoked is a proxy
Mobile IPv6 binding. Mobile IPv6 binding.
o The Global (G) bit MUST be set and the Revocation Trigger contains o The Global (G) bit MUST be set and the Revocation Trigger contains
a value of "Per-Peer Policy" in the Binding Revocation Indication a value of "Per-Peer Policy" in the Binding Revocation Indication
to request the LMA to remove all Per-Peer bindings that are to request the LMA to remove all Per-Peer bindings that are
registered with the LMA and hosted at this MAG. In this case, the registered with the LMA and hosted at this MAG. In this case, the
MN-ID option MUST be included in the BRI and contains the mobile MN-ID option MUST be included in the BRI and contains the mobile
access gateway identity. access gateway identity. In this case the mobile access gateway
MAY include one or more Alternate Care-of Address option(s). The
Alternate Care-of Address option(s) include the proxy Care-of
address(es) which their bindings are being impacted by this BRI
message.
o The mobile access gateway address MAY be used as the Source 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 BRA in response to this Binding
Revocation Indication. As described in Section 7.3, the mobile Revocation Indication. As described in Section 7.3, the mobile
access gateway SHOULD retransmit this BRI to the local mobility access gateway SHOULD retransmit this BRI to the local mobility
anchor until it receives a matching BRA or the BRIMaxRetransmitNumber anchor until it receives a matching BRA or the BRIMaxRetransmitNumber
is reached. The mobile access gateway MAY delete the mobile nodes IP is reached. The mobile access gateway MAY delete the mobile nodes IP
tunnels immediately after sending the Binding Revocation Indication tunnels immediately after sending the Binding Revocation Indication
before receiving a BRA message from the LMA. before receiving a BRA message from the LMA.
10.2.2. Receiving Binding Revocation Acknowledgement 10.2.2. Receiving Binding Revocation Acknowledgement
When the mobile access gateway receive 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 validate the according to Section 7.2, the mobile access gateway MUST process the
BRA as per the followings: BRA as per the followings:
o When the mobile access gateway receive 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
MIPv6 (P) bits are set and the mobile nodes BCEs are in the state MIPv6 (P) bits are set and the mobile nodes BCEs are in the state
of Revocation in Progress, the mobile access gateway SHOULD 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
and all associated resources. and all associated resources.
skipping to change at page 29, line 33 skipping to change at page 30, line 42
11. Mobile Node Operation 11. Mobile Node Operation
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. routing header is its Home Address and that its Binding Update
List contains an entry for that Home Address. If one of the
tests, fails the mobile node SHOULD silently discard the received
BRI message.
o If the Acknowledgement (A) bit is set in the Binding Revocation o If the Acknowledgement (A) bit is set in the Binding Revocation
Indication and the MN has the BCE in registered state, the mobile Indication and its Binding Update List contains an entry for the
node MUST send a Binding Revocation Acknowledgement. However, in IP address in the type 2 routing header, the mobile node MUST send
all other cases when the (A) bit is set in the BRI, the mobile a Binding Revocation Acknowledgement. However, in all other cases
node SHOULD send a Binding Revocation Acknowledgement. In all when the (A) bit is set in the BRI, the mobile node SHOULD send a
cases, the mobile node MUST follow Section 11.2 when send a BRA Binding Revocation Acknowledgement. In all cases, the mobile node
using the appropriate status code. MUST follow Section 11.2 and send a BRA using the appropriate
status code.
o If the IPv4 HoA Binding Only (V) bit is set in the received BRI
message, the MN MUST verify that there is an IPv4 HoA option in
the received BRI and the IPv4 address included in the IPv4 Home
Address option is the same as its IPv4 HoA that is assigned to the
mobile node. If this verification is successful, the MN MUST
consider this BRI as an indication to release the mobile node IPv4
HoA binding to its current Care-of Address ONLY. Consequently,
the MN MUST continue to maintain its IPv6 HoA binding to the
current CoA as part of the mobile node binding in the BUL entry
and release all resources associated with the MN IPv4 HoA binding.
In this case, the MN MUST send a BRA message with the status field
is set to success. On the other hand, if the IPv4 HoA option was
NOT included in the received BRI with the (V) bit set, the MN
SHOULD send a BRA message with the status field set to "IPv4 HoA
Option Required". Additionally, if the verification received IPv4
HoA in the IPv4 HoA option is NOT the one assigned to the MN, the
MN SHOULD send a BRA with the status field is set to "IPv4 HoA
Binding Does NOT Exist".
o The mobile node MUST verify that the (P) bit in the Binding 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 Revocation Trigger field value is "Administrative Reason",
the mobile node MUST NOT try to re-register with the home agent
before contacting its home operator.
o If the mobile node has registered multiple care-of addresses with o If the mobile node has registered multiple care-of addresses with
its home agent, the mobile node MUST verify which binding is being its home agent, the mobile node MUST verify which binding is being
revoked by examining the content of the BRI message. If the revoked by examining the content of the BRI message. If the
mobile node received a Binding Revocation Indication with a single mobile node received a Binding Revocation Indication with a single
or more than one Binding ID options and its home address is or more than one Binding ID options and its home address is
included in the type 2 routing header, the mobile node MUST included in the type 2 routing header, the mobile node MUST
consider all of the care-of address(es) binding(s), identified in consider all of the care-of address(es) binding(s), identified in
the Binding ID options, with this home address are being revoked. the Binding ID options, with this home address are being revoked.
o If the mobile node has multi Care-of Addresses bindings with its o If the mobile node has multi Care-of Addresses bindings with its
skipping to change at page 30, line 28 skipping to change at page 32, line 9
its registered care-of addresses bindings with this home address its registered care-of addresses bindings with this home address
are being revoked. are 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 receive a valid Binding Revocation Indication When the mobile node receives a Binding Revocation Indication from
with the (A) bit is set from its home agent and while having this BCE its home agent, the mobile node processes the received BRI as in
in registered state, the mobile node MUST send a packet to its home Section 11.1. If the mobile node is required to send a BRA message
agent containing a Binding Revocation Acknowledgement according to in response to the received BRI, the mobile node sends a packet to
the procedure in Section 7.1 and the following: 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 successful to reflect o The mobile node MUST set the status field to an appropriate value.
that it has received the Binding Revocation Indication and The mobile node sets the status field to success to reflect that
acknowledge that its IP connectivity with its home agent has been it has received the Binding Revocation Indication and acknowledge
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
option in the Destination Option. Destination Option.
o If the mobile node receives a Binding Revocation Indication from a
home agent which the mobile node does not have a registered
binding with, the mobile node SHOULD silently discard the BRI
message. The mobile node should continue to use its assigned HoA
to access its IP mobility service.
12. Protocol Configuration Variables 12. Protocol Configuration Variables
Any mobility entity which is allowed to invoke the binding revocation Any mobility entity which is allowed to invoke the binding revocation
procedure by sending a Binding Revocation Indication message SHOULD procedure by sending a Binding Revocation Indication message SHOULD
allow the following variables to be configured. allow the following variables to be configured.
BRI Maximum Number of Retries (BRIMaxRetriesNumber) BRI Maximum Number of Retries (BRIMaxRetriesNumber)
This variable specifies the maximum Number of times a mobility This variable specifies the maximum Number of times a mobility
skipping to change at page 31, line 49 skipping to change at page 33, line 25
MUST allow the MH type for the Binding Revocation Message defined in MUST allow the MH type for the Binding Revocation Message defined in
this document. this document.
However, in the case when the MAG sends a BRI message with the Global However, in the case when the MAG sends a BRI message with the Global
(G) bit is set, the LMA MUST verify that the MAG is authorized to use (G) bit is set, the LMA MUST verify that the MAG is authorized to use
Per-Peer Global Revocation. 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 for their review and comments of this draft Cazavet, Domagoj Premec, Arnaud Ebalard, and Patrick Stupar for their
and all colleagues who have supported the advancement of this draft review and comments of this draft and all colleagues who have
effort. supported the advancement of this draft effort.
16. References 16. References
16.1. Normative References 16.1. Normative References
[ID-DSMIP6] [ID-DSMIP6]
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", draft-ietf-mext-nemo-v4traversal-06 (work in Routers", draft-ietf-mext-nemo-v4traversal-07 (work in
progress), November 2008. progress), December 2008.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration", "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-10 (work in progress), draft-ietf-monami6-multiplecoa-11 (work in progress),
November 2008. January 2009.
[ID-PMIP6-IPv4] [ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-05 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09
(work in progress), September 2008. (work in progress), January 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
skipping to change at page 34, line 4 skipping to change at line 1535
Email: kchowdhury@starentnetworks.com Email: kchowdhury@starentnetworks.com
Parviz Yegani Parviz Yegani
Juniper Networks Juniper Networks
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: pyegani@juniper.net Email: pyegani@juniper.net
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 74 change blocks. 
234 lines changed or deleted 321 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/