draft-ietf-mext-binding-revocation-08.txt   draft-ietf-mext-binding-revocation-09.txt 
Network Working Group A. Muhanna Network Working Group A. Muhanna
Internet-Draft M. Khalil Internet-Draft M. Khalil
Intended status: Standards Track Nortel Intended status: Standards Track Nortel
Expires: February 13, 2010 S. Gundavelli Expires: February 16, 2010 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Startent Networks Starent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
August 12, 2009 August 15, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-08.txt draft-ietf-mext-binding-revocation-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 48 skipping to change at page 1, line 48
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 13, 2010. This Internet-Draft will expire on February 16, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 26 skipping to change at page 3, line 26
3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding
Revocation . . . . . . . . . . . . . . . . . . . . . . 10 Revocation . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11
4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Binding Revocation Messages over IPv4 Transport Network . . . 12 5. Binding Revocation Messages over IPv4 Transport Network . . . 12
6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 13 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 13
6.1. Binding Revocation Indication Message . . . . . . . . . . 14 6.1. Binding Revocation Indication Message . . . . . . . . . . 14
6.2. Binding Revocation Acknowledgement Message . . . . . . . . 17 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 17
7. Binding Revocation Process Operation . . . . . . . . . . . . . 20 7. Binding Revocation Process Operation . . . . . . . . . . . . . 20
7.1. Sending Binding Revocation Messages . . . . . . . . . . . 20 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 20
7.2. Receiving Binding Revocation Messages . . . . . . . . . . 20 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 21
7.3. Retransmission of Binding Revocation Indication . . . . . 22 7.3. Retransmission of Binding Revocation Indication . . . . . 22
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
8.1. Sending Binding Revocation Indication . . . . . . . . . . 22 8.1. Sending Binding Revocation Indication . . . . . . . . . . 22
8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 23 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 24
9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24
9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24
9.1.1. Sending Binding Revocation Indication . . . . . . . . 24 9.1.1. Sending Binding Revocation Indication . . . . . . . . 24
9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 28 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 28
9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29
9.2.1. Receiving Binding Revocation Indication . . . . . . . 29 9.2.1. Receiving Binding Revocation Indication . . . . . . . 29
9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 30 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 30
10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 31 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 31
10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 31 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 31
10.1.1. Receiving Binding Revocation Indication . . . . . . . 31 10.1.1. Receiving Binding Revocation Indication . . . . . . . 31
10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 33 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 33
10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 33 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 34
10.2.1. Sending Binding Revocation Indication . . . . . . . . 33 10.2.1. Sending Binding Revocation Indication . . . . . . . . 34
10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 34 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 35
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 35 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 35
11.1. Receiving Binding Revocation Indication . . . . . . . . . 35 11.1. Receiving Binding Revocation Indication . . . . . . . . . 35
11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 36 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 37
12. Protocol Configuration Variables . . . . . . . . . . . . . . . 37 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
14. Security Considerations . . . . . . . . . . . . . . . . . . . 39 14. Security Considerations . . . . . . . . . . . . . . . . . . . 39
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
16.1. Normative References . . . . . . . . . . . . . . . . . . . 40 16.1. Normative References . . . . . . . . . . . . . . . . . . . 40
16.2. Informative References . . . . . . . . . . . . . . . . . . 40 16.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
In the case of Mobile IPv6 and for administrative reason, sometimes In the case of Mobile IPv6 and for administrative reason, sometimes
it becomes necessary to inform the mobile node that its registration it becomes necessary to inform the mobile node that its registration
has been revoked and the mobile node is no longer able to receive IP has been revoked and the mobile node is no longer able to receive IP
mobility service using its Home Address. A similar Mobile IPv4 mobility service using its Home Address. A similar Mobile IPv4
registration revocation mechanism [RFC3543] has been specified by registration revocation mechanism [RFC3543] has been specified by
IETF for providing a revocation mechanism for sessions that were IETF for providing a revocation mechanism for sessions that were
established using Mobile IPv4 registration [RFC3344]. established using Mobile IPv4 registration [RFC3344].
skipping to change at page 6, line 37 skipping to change at page 6, line 37
Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation
procedure can be initiated by the local mobility anchor by sending a procedure can be initiated by the local mobility anchor by sending a
Binding Revocation Indication message to communicate the termination Binding Revocation Indication message to communicate the termination
of a mobile node registration binding to the mobile access gateway. of a mobile node registration binding to the mobile access gateway.
In this case, the local mobility anchor includes the mobile node Home In this case, the local mobility anchor includes the mobile node Home
Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option Network Prefix (MN-HNP) option [RFC5213] and the MN-ID option
[RFC4283] to indicate to the mobility access gateway the identity of [RFC4283] to indicate to the mobility access gateway the identity of
the PMIPv6 binding that needs to be terminated. When the mobile the PMIPv6 binding that needs to be terminated. When the mobile
access gateway receives the Binding Revocation Indication message access gateway receives the Binding Revocation Indication message
with the (A) bit set, the mobile access gateway responds to the local with the Acknowledge (A) bit set, the mobile access gateway responds
mobility anchor by sending a Binding Revocation Acknowledgement to the local mobility anchor by sending a Binding Revocation
message. Acknowledgement message.
On the other hand, the mobile access gateway usually sends a de- On the other hand, the mobile access gateway usually sends a de-
registration message by sending a Proxy Binding Update with a registration message by sending a Proxy Binding Update with a
lifetime of zero to indicate to the local mobility anchor of the lifetime of zero to indicate to the local mobility anchor of the
termination of the PMIPv6 mobile node binding registration. In this termination of the PMIPv6 mobile node binding registration. In this
case, the mobile access gateway includes the MN-HNP option, the MN-ID case, the mobile access gateway includes the MN-HNP option, the MN-ID
option and all other required mobility options as per [RFC5213] in option and all other required mobility options as per [RFC5213] in
order for the local mobility anchor to identify the mobile node order for the local mobility anchor to identify the mobile node
PMIPv6 binding. Additionally, in the case when the mobile access PMIPv6 binding. Additionally, in the case when the mobile access
gateway communicates a bulk termination of PMIPv6 mobility sessions, gateway communicates a bulk termination of PMIPv6 mobility sessions,
the mobile access gateway sends a Binding Revocation Indication the mobile access gateway sends a Binding Revocation Indication
message with the (G) and (A) bits set and includes the mobile access message with the Global (G) and Acknowledge (A) bits set and includes
gateway identity in the MN-ID option. When the local mobility anchor the mobile access gateway identity in the MN-ID option. When the
receives such Binding Revocation Indication message, it ensures that local mobility anchor receives such Binding Revocation Indication
the mobile access gateway is authorized to send such bulk termination message, it ensures that the mobile access gateway is authorized to
message and then processes the Binding Revocation Indication message send such bulk termination message and then processes the Binding
accordingly. If the local mobility anchor processes the Binding Revocation Indication message accordingly. If the local mobility
Revocation Indication message successfully, the local mobility anchor anchor processes the Binding Revocation Indication message
responds to the mobile access gateway by sending Binding Revocation successfully, the local mobility anchor responds to the mobile access
Acknowledgement message. gateway by sending Binding Revocation Acknowledgement message.
In any of the above cases, the initiator of the binding revocation In any of the above cases, the initiator of the binding revocation
procedure, e.g., home agent, local mobility anchor, mobile access procedure, e.g., home agent, local mobility anchor, mobile access
gateway, uses the Revocation Trigger field in the Binding Revocation gateway, uses the Revocation Trigger field in the Binding Revocation
Indication message to indicate to the receiving node the reason for Indication message to indicate to the receiving node the reason for
initiating the revocation procedure. initiating the revocation procedure.
3.2. MIPv6 and DSMIP6 Use Case 3.2. MIPv6 and DSMIP6 Use Case
Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6 Binding revocation mechanism is applicable to Mobile IPv6 and DSMIPv6
skipping to change at page 9, line 46 skipping to change at page 9, line 46
anchor, are always synchronized with respect to the status of the anchor, are always synchronized with respect to the status of the
existing PMIPv6 bindings. The binding revocation mechanism is existing PMIPv6 bindings. The binding revocation mechanism is
generic enough that can be used for all Proxy Mobile IPv6 scenarios generic enough that can be used for all Proxy Mobile IPv6 scenarios
that follow [RFC5213] and [ID-PMIP6-IPv4] specifications. that follow [RFC5213] and [ID-PMIP6-IPv4] specifications.
When the mobile access gateway receives a Binding Revocation When the mobile access gateway receives a Binding Revocation
Indication message as in Section 10.1.1, the mobile access gateway Indication message as in Section 10.1.1, the mobile access gateway
sends a Binding Revocation Acknowledgement message to the local sends a Binding Revocation Acknowledgement message to the local
mobility anchor following the rules described in Section 10.1.2. mobility anchor following the rules described in Section 10.1.2.
Similarly, if the local mobility anchor receives a Binding Revocation Similarly, if the local mobility anchor receives a Binding Revocation
Indication message with the (A) bit is set, the local mobility anchor Indication message with the Acknowledge (A) bit is set, the local
responds to the mobile access gateway by sending a Binding Revocation mobility anchor responds to the mobile access gateway by sending a
Acknowledgement message. Binding Revocation Acknowledgement message.
3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding Revocation
The local mobility anchor may send a Binding Revocation Indication The local mobility anchor may send a Binding Revocation Indication
message to the mobile access gateway, hosting a specific PMIPv6 message to the mobile access gateway, hosting a specific PMIPv6
binding, with the appropriate value in the revocation trigger field binding, with the appropriate value in the revocation trigger field
to indicate that the mobile node binding has been terminated and the to indicate that the mobile node binding has been terminated and the
mobile access gateway can clean up the applicable resources. When mobile access gateway can clean up the applicable resources. When
the mobile access gateway receives a Binding Revocation Indication the mobile access gateway receives a Binding Revocation Indication
message, the mobile access gateway identifies the respected binding message, the mobile access gateway identifies the respected binding
and if the (A) bit was set in the received Binding Revocation and if the Acknowledge (A) bit was set in the received Binding
Indication message, it sends a Binding Revocation Acknowledgement Revocation Indication message, it sends a Binding Revocation
message to the local mobility anchor. In this case, the mobile Acknowledgement message to the local mobility anchor. In this case,
access gateway could send a Router Advertisement message to the the mobile access gateway could send a Router Advertisement message
mobile node with the home network prefix valid lifetime set to zero. to the mobile node with the home network prefix valid lifetime set to
zero.
As an example, Figure 3, illustrates the message sequence for As an example, Figure 3, illustrates the message sequence for
revoking a mobile node binding at the source mobile access gateway revoking a mobile node binding at the source mobile access gateway
during the mobile node inter-MAG handover. During the inter-MAG during the mobile node inter-MAG handover. During the inter-MAG
handover, the mobile node moves from the source MAG to the target handover, the mobile node moves from the source MAG to the target
MAG. The target MAG sends a Proxy Binding Update with the new care- MAG. The target MAG sends a Proxy Binding Update with the new care-
of-address to the local mobility anchor to update the mobile node's of-address to the local mobility anchor to update the mobile node's
point of attachment. Since the mobile node binding at the local point of attachment. Since the mobile node binding at the local
mobility anchor points to the source MAG and upon receiving the Proxy mobility anchor points to the source MAG and upon receiving the Proxy
Binding Update from the target MAG, the local mobility anchor updates Binding Update from the target MAG, the local mobility anchor updates
skipping to change at page 11, line 32 skipping to change at page 11, line 32
| BRA [seq.#, Status, P bit] | | BRA [seq.#, Status, P bit] |
|----------------------------------------->| |----------------------------------------->|
| | | | | |
| | | | | |
Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover
In addition, the local mobility anchor can send a Binding Revocation In addition, the local mobility anchor can send a Binding Revocation
Indication message to indicate that all bindings which are hosted by Indication message to indicate that all bindings which are hosted by
the peer mobile access gateway and registered with the local mobility the peer mobile access gateway and registered with the local mobility
anchor are being revoked by setting the (G) bit as described in anchor are being revoked by setting the Global (G) bit as described
Section 9.1.1. in Section 9.1.1.
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings
The mobile access gateway sends a BRI message with the (G) bit is set The mobile access gateway sends a BRI message with the Global (G) bit
to indicate that all mobility bindings which are registered at the is set to indicate that all mobility bindings which are registered at
local mobility anchor and attached to the mobile access gateway are the local mobility anchor and attached to the mobile access gateway
being revoked as in Section 10.2.1. When the local mobility anchor are being revoked as in Section 10.2.1. When the local mobility
receives a Binding Revocation Indication message with the (G) bit is anchor receives a Binding Revocation Indication message with the
set from a specified mobile access gateway, the local mobility anchor Global (G) bit is set from a specified mobile access gateway, the
first checks if the mobile access gateway is authorized to use global local mobility anchor first checks if the mobile access gateway is
revocations and then responds with the appropriate status code by authorized to use global revocations and then responds with the
sending a Binding Revocation Acknowledgement message as in appropriate status code by sending a Binding Revocation
Section 9.2.2. Acknowledgement message as in Section 9.2.2.
4. Security Model 4. Security Model
The binding revocation protocol described here uses the same security The binding revocation protocol described here uses the same security
association between the mobile node and the home agent or the mobile association between the mobile node and the home agent or the mobile
access gateway and the local mobility anchor that has been used to access gateway and the local mobility anchor that has been used to
exchange the corresponding MIPv6 or PMIPv6 Binding Update and Binding exchange the corresponding MIPv6 or PMIPv6 Binding Update and Binding
Acknowledgement when the mobile node binding was created. If IPsec Acknowledgement when the mobile node binding was created. If IPsec
is used, the traffic selectors associated with the SPD entry is used, the traffic selectors associated with the SPD entry
protecting the Binding Update and Binding Acknowledgement MUST be protecting the Binding Update and Binding Acknowledgement MUST be
extended to include Binding Revocation Signaling MH type <IANA-TBD>. extended to include Binding Revocation Signaling MH type <IANA-TBD>.
Extending the traffic selectors of the SPD entry in order to reuse Extending the traffic selectors of the SPD entry in order to reuse
the SA protecting Binding Update and Binding Acknowledgement (instead the SA protecting Binding Update and Binding Acknowledgement (instead
of creating new ones) ensures that those SA will be up and running of creating new ones) ensures that those SA will be up and running
when the revoking entity needs to send a binding revocation signaling when the revoking entity needs to send a binding revocation signaling
message. message.
Additionally, in the case when the local mobility anchor receives a Additionally, in the case when the local mobility anchor receives a
Binding Revocation Indication which indicates a bulk termination Binding Revocation Indication which indicates a bulk termination
where the (G) bit is set and the Revocation Trigger field is set to where the Global (G) bit is set and the Revocation Trigger field is
"Per-Peer Policy", the local mobility anchor MUST verify that the set to "Per-Peer Policy", the local mobility anchor MUST verify that
mobile access gateway sending the binding revocation indication the mobile access gateway sending the binding revocation indication
message is authorized to invoke global revocation. message is authorized to invoke global revocation.
5. Binding Revocation Messages over IPv4 Transport Network 5. Binding Revocation Messages over IPv4 Transport Network
In some deployments, the network between the mobile access gateway In some deployments, the network between the mobile access gateway
and the local mobility anchor may only support IPv4 transport. and the local mobility anchor may only support IPv4 transport.
Another case is when a mobile node which support client mobile IPv6 Another case is when a mobile node which supports client mobile IPv6
roam to an access network where only IPv4 addressing and transport is roams to an access network where only IPv4 addressing and transport
supported. In this case, the mobile node is required to register an is supported. In this case, the mobile node is required to register
IPv4 home address with its home agent using a mobile IPv6 Binding an IPv4 home address with its home agent using a mobile IPv6 Binding
Update message. Update message.
If the Proxy Binding Update and Proxy Binding Acknowledgment messages If the Proxy Binding Update and Proxy Binding Acknowledgement
or the Binding Update and Binding Acknowledgement messages are sent messages or the Binding Update and Binding Acknowledgement messages
using UDP encapsulation to traverse NATs, then the Binding Revocation are sent using UDP encapsulation to traverse NATs, then the Binding
messages are sent using the same UDP encapsulation. The same UDP Revocation messages are sent using the same UDP encapsulation. The
port that was used for exchanging the Proxy Binding Update and Proxy same UDP source and destination port numbers and IPv4 addresses used
Binding Acknowledgement or the Binding Update and Binding for exchanging the Proxy Binding Update and Proxy Binding
Acknowledgement messages will also be used when transporting Binding Acknowledgement or the Binding Update and Binding Acknowledgement
Revocation messages over IPv4 using UDP encapsulation. In other messages will also be used when transporting Binding Revocation
words, the destination UDP port of the Binding Revocation Indication messages over IPv4 using UDP encapsulation. For example, the source
message MUST be set to the source UDP port of the latest successfully UDP port number, the destination UDP port number, the source IPv4
processed Proxy Binding Update or Binding Update message which is address, and the destination IPv4 address of the Binding Revocation
already saved in the mobile node BCE. For more details on tunneling Indication message MUST be set to the destination UDP port number,
Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see the source UDP port number, destination IPv4 address, and source IPv4
[ID-PMIP6-IPv4] and [RFC5555], respectively. address of the latest successfully processed Proxy Binding Update or
Binding Update message received, respectively. For more details on
tunneling Proxy Mobile IPv6 and Mobile IPv6 signaling messages over
IPv4, see [ID-PMIP6-IPv4] and [RFC5555], respectively.
6. Binding Revocation Message 6. Binding Revocation Message
This section defines the Binding Revocation Message format using a MH This section defines the Binding Revocation Message format using a MH
Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding
Revocation Type field defines whether the Binding Revocation message Revocation Type field defines whether the Binding Revocation message
is a Binding Revocation Indication or Binding Revocation is a Binding Revocation Indication or Binding Revocation
Acknowledgement. If the Binding Revocation type field is set to 1, Acknowledgement. If the Binding Revocation type field is set to 1,
the Binding Revocation Message is a Binding Revocation Indication as the Binding Revocation Message is a Binding Revocation Indication as
in Section 6.1. However, if the value is 2, it is a Binding in Section 6.1. However, if the value is 2, it is a Binding
skipping to change at page 15, line 15 skipping to change at page 15, line 28
Revocation Trigger Revocation Trigger
8-bit unsigned integer indicating the event which triggered the 8-bit unsigned integer indicating the event which triggered the
revoking node to send the BRI message. The Reserved and Per-MN revoking node to send the BRI message. The Reserved and Per-MN
Revocation Triggers value are less than 128 except the reserved Revocation Triggers value are less than 128 except the reserved
values 250-255. The per-MN revocation triggers is used when the values 250-255. The per-MN revocation triggers is used when the
BRI message intends to revoke one or more bindings for the same BRI message intends to revoke one or more bindings for the same
mobile node. The Global Revocation Trigger values are greater mobile node. The Global Revocation Trigger values are greater
than 128 and less than 250 and used in the BRI message with the than 128 and less than 250 and used in the BRI message with the
(G) bit set for global revocation. The following Revocation Global (G) bit set for global revocation. The following
Trigger values are currently defined: Revocation Trigger values are currently defined:
Reserved and Per-MN Revocation Trigger: Reserved and Per-MN Revocation Trigger:
0 Reserved 0 Reserved
1 Unspecified 1 Unspecified
2 Administrative Reason 2 Administrative Reason
3 Inter-MAG Handover - same Access Type 3 Inter-MAG Handover - same Access Type
4 Inter-MAG Handover - different Access Type 4 Inter-MAG Handover - different Access Type
5 Inter-MAG Handover - Unknown 5 Inter-MAG Handover - Unknown
6 User Initiated Session(s) Termination 6 User Initiated Session(s) Termination
7 Access Network Session(s) Termination 7 Access Network Session(s) Termination
skipping to change at page 16, line 48 skipping to change at page 17, line 15
the specific binding or bindings that the sending mobility entity the specific binding or bindings that the sending mobility entity
requesting to be revoked. requesting to be revoked.
The following options are valid in a Binding Revocation Indication: The following options are valid in a Binding Revocation Indication:
o Home Network Prefix option [RFC5213]. This option MAY be used o Home Network Prefix option [RFC5213]. This option MAY be used
when the (P) bit is set. This option MUST be present when the BRI when the (P) bit is set. This option MUST be present when the BRI
is used to revoke a single PMIP binding cache entry. is used to revoke a single PMIP binding cache entry.
o Mobile Node Identifier Option [RFC4283]. This option is mandatory o Mobile Node Identifier Option [RFC4283]. This option is mandatory
when the (P) bit is set. Additionally, if the (G) bit is set by when the (P) bit is set. Additionally, if the Global (G) bit is
the mobile access gateway, this option carries the MAG identity. set by the mobile access gateway, this option carries the MAG
identity.
o Binding Identifier mobility option [ID-MCoA]. This option is o Binding Identifier mobility option [ID-MCoA]. This option is
mandatory if the sending mobility entity requests to terminate one mandatory if the sending mobility entity requests to terminate one
binding of a multi care-of addresses bindings for the same mobile binding of a multi care-of addresses bindings for the same mobile
node. The sending mobility entity may include more than one of node. The sending mobility entity may include more than one of
the BID mobility options. the BID mobility options.
o IPv4 Home Address option which contains the mobile node home IPv4 o IPv4 Home Address option which contains the mobile node home IPv4
address [RFC5555]. This option is included only when the IPv4 HoA address [RFC5555]. This option is included only when the IPv4 HoA
Binding only (V) bit is set. Binding only (V) bit is set.
skipping to change at page 20, line 26 skipping to change at page 20, line 34
In addition, the mobility entity which initiates the binding In addition, the mobility entity which initiates the binding
revocation process by sending a Binding Revocation Indication revocation process by sending a Binding Revocation Indication
message, initiator, MUST construct the Binding Revocation Message message, initiator, MUST construct the Binding Revocation Message
Data following the format of the Binding Revocation Indication Data following the format of the Binding Revocation Indication
message as described in Section 6.1. In the BRI message, the message as described in Section 6.1. In the BRI message, the
initiator MUST set the Sequence Number field to the next sequence initiator MUST set the Sequence Number field to the next sequence
number available for Binding Revocation. Since sending Binding number available for Binding Revocation. Since sending Binding
Revocation Indication message is not done on a regular basis, a 16 Revocation Indication message is not done on a regular basis, a 16
bit sequence number field is large enough to allow the initiator to bit sequence number field is large enough to allow the initiator to
match the Binding Revocation Acknowledgement to the outstanding match the Binding Revocation Acknowledgement to the outstanding
Binding Revocation Indication with (A) bit set using the sequence Binding Revocation Indication with Acknowledge (A) bit set using the
number field only. sequence number field only.
However, when the responder acknowledges the Binding Revocation However, when the responder acknowledges the Binding Revocation
Indication message, the responder MUST constructs the Binding Indication message, the responder MUST constructs the Binding
Revocation message packet as it would any other Mobility Header with Revocation message packet as it would any other Mobility Header with
the exception of setting the MH Type field to <IANA-TBD>. It also the exception of setting the MH Type field to <IANA-TBD>. It also
MUST construct the Binding Revocation Message Data following the MUST construct the Binding Revocation Message Data following the
format of the Binding Revocation Acknowledgement message as described format of the Binding Revocation Acknowledgement message as described
in Section 6.2. In this case, the responder MUST set the Sequence in Section 6.2. In this case, the responder MUST set the Sequence
Number field by copying the value from the Sequence Number field of Number field by copying the value from the Sequence Number field of
the received Binding Revocation Indication. Additionally, it MUST the received Binding Revocation Indication. Additionally, it MUST
skipping to change at page 21, line 43 skipping to change at page 22, line 8
If a mobility node receives a Binding Revocation Indication message If a mobility node receives a Binding Revocation Indication message
with the Revocation Trigger field is set to a value that NOT with the Revocation Trigger field is set to a value that NOT
supported, the receiving mobility node SHOULD reject the Binding supported, the receiving mobility node SHOULD reject the Binding
Revocation Indication message by sending a Binding Revocation Revocation Indication message by sending a Binding Revocation
Acknowledgement message with the Status field set to "Revocation Acknowledgement message with the Status field set to "Revocation
Trigger NOT Supported". Trigger NOT Supported".
If a mobility node receives a Binding Revocation Indication message If a mobility node receives a Binding Revocation Indication message
with a Revocation Trigger value that is NOT in line with the Binding with a Revocation Trigger value that is NOT in line with the Binding
Revocation Indication message intent, e.g., the Global Revocation (G) Revocation Indication message intent, e.g., the Global (G) bit set
bit set and the Revocation Trigger field vale is a per-MN specific, and the Revocation Trigger field vale is a per-MN specific, the
the receiving mobility node SHOULD reject the Binding Revocation receiving mobility node SHOULD reject the Binding Revocation
Indication message by sending a Binding Revocation Acknowledgement Indication message by sending a Binding Revocation Acknowledgement
message with the Status field set to "Revocation Function NOT message with the Status field set to "Revocation Function NOT
Supported". Supported".
7.3. Retransmission of Binding Revocation Indication 7.3. Retransmission of Binding Revocation Indication
If the sending mobility entity does not receive a Binding Revocation If the sending mobility entity does not receive a Binding Revocation
Acknowledgement in response to the outstanding initial Binding Acknowledgement in response to the outstanding initial Binding
Revocation Indication before the InitMINDelayBRIs timer expires, the Revocation Indication before the InitMINDelayBRIs timer expires, the
mobility entity, e.g. LMA, SHOULD retransmit the same BRI message up mobility entity, e.g. LMA, SHOULD retransmit the same BRI message up
skipping to change at page 23, line 24 skipping to change at page 23, line 33
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the mobile node to return a Binding Revocation Acknowledgement in the mobile node to return a Binding Revocation Acknowledgement in
response to this Binding Revocation Indication. As described in response to this Binding Revocation Indication. As described in
Section 7.3, the home agent SHOULD retransmit this Binding Revocation Section 7.3, the home agent SHOULD retransmit this Binding Revocation
Indication to the mobile node before terminating its IP connection Indication to the mobile node before terminating its IP connection
until it receives a matching Binding Revocation Acknowledgement or until it receives a matching Binding Revocation Acknowledgement or
the BRIMaxRetransmitNumber has been reached. the BRIMaxRetransmitNumber has been reached.
When the home agent sends a Binding Revocation Indication to the When the home agent sends a Binding Revocation Indication to the
mobile node with the (A) bit set, the home agent sets a flag in the mobile node with the Acknowledge (A) bit set, the home agent sets a
mobile node BCE to indicate that revocation is in progress and starts flag in the mobile node BCE to indicate that revocation is in
the InitMINDelayBRIs timer. The home agent maintains the mobile node progress and starts the InitMINDelayBRIs timer. The home agent
BCE in this state until it receives a Binding Revocation maintains the mobile node BCE in this state until it receives a
Acknowledgement or retransmits the Binding Revocation Indication Binding Revocation Acknowledgement or retransmits the Binding
message as described in Section 7.3. Revocation Indication message as described in Section 7.3.
In a race condition case, the home agent may receive a Binding Update In a race condition case, the home agent may receive a Binding Update
from the mobile node while the mobile node's BCE has the revocation from the mobile node while the mobile node's BCE has the revocation
in progress flag set, the home agent SHOULD handle this case based on in progress flag set, the home agent SHOULD handle this case based on
the reason for sending the Binding Revocation Indication message and the reason for sending the Binding Revocation Indication message and
its local policy. In this case, if the home agent accepts the its local policy. In this case, if the home agent accepts the
Binding Update, it needs to update the mobile node BCE accordingly, Binding Update, it needs to update the mobile node BCE accordingly,
e.g. removing the revocation in progress flag. e.g. removing the revocation in progress flag.
When the home agent needs to revoke one or more of a mobile node When the home agent needs to revoke one or more of a mobile node
skipping to change at page 27, line 8 skipping to change at page 27, line 18
considers the received Proxy Binding Update message as a request for considers the received Proxy Binding Update message as a request for
a new BCE and if processed successfully, the local mobility anchor a new BCE and if processed successfully, the local mobility anchor
assigns a different HNP for the new BCE. assigns a different HNP for the new BCE.
This document updates the local mobility anchor's behavior in this This document updates the local mobility anchor's behavior in this
case. If the local mobility anchor supports the binding revocation case. If the local mobility anchor supports the binding revocation
mechanism as described in this document, it SHOULD proactively send a mechanism as described in this document, it SHOULD proactively send a
Binding Revocation Indication message to the previous mobile access Binding Revocation Indication message to the previous mobile access
gateway instead of waiting for a de-registration from the previous gateway instead of waiting for a de-registration from the previous
mobile access gateway. In the Binding Revocation Indication message, mobile access gateway. In the Binding Revocation Indication message,
the (A) bit MUST be set and the Revocation Trigger MUST be set to the Acknowledge (A) bit MUST be set and the Revocation Trigger MUST
"Inter-MAG Handover - Unknown". be set to "Inter-MAG Handover - Unknown".
If the local mobility anchor sent a Binding Revocation Indication If the local mobility anchor sent a Binding Revocation Indication
message with the Revocation Trigger field set to "Inter-MAG Handover message with the Revocation Trigger field set to "Inter-MAG Handover
- Unknown" and while waiting for a Binding Revocation Acknowledgement - Unknown" and while waiting for a Binding Revocation Acknowledgement
response, the following are possible conditions that the local response, the following are possible conditions that the local
mobility anchor MUST handle as specified below: mobility anchor MUST handle as specified below:
o If the local mobility anchor receives a successful Binding o If the local mobility anchor receives a successful Binding
Revocation Acknowledgement message or a de-registration message Revocation Acknowledgement message or a de-registration message
from the previous mobile access gateway, the local mobility anchor from the previous mobile access gateway, the local mobility anchor
skipping to change at page 28, line 34 skipping to change at page 28, line 43
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:
o If the Status field indicates that the BRI was processed o If the Status field indicates that the BRI was processed
successfully, the local mobility anchor delete the current timer successfully, the local mobility anchor MUST delete the current
and the mobile node proxy bindings and all associated resources. timer and the mobile node proxy bindings and all associated
resources.
o If the Status field indicates partial success value or MN binding o If the Status field indicates partial success value or MN binding
does not exist, the local mobility anchor SHOULD examine mobility does not exist, the local mobility anchor SHOULD examine mobility
options that are included in the Binding Revocation options that are included in the Binding Revocation
Acknowledgement, if any, before deleting the current timer and the Acknowledgement, if any, before deleting the current timer and the
mobile node associated proxy bindings and other related resources. mobile node associated proxy bindings and other related resources.
It is based on the local mobility anchor local policy how to It is based on the local mobility anchor local policy how to
handle the mobile node BCE(s) that the mobile access gateway handle the mobile node BCE(s) that the mobile access gateway
indicated it failed the revocation procedure, however, the LMA MAY indicated it failed the revocation procedure, however, the LMA MAY
log the event. log the event.
skipping to change at page 29, line 39 skipping to change at page 29, line 49
option is included, the local mobility anchor MUST revoke all option is included, the local mobility anchor MUST revoke all
mobile nodes bindings which proxy CoA is the one used as the mobile nodes bindings which proxy CoA is the one used as the
source of the IPv6 packet that carried the Binding Revocation source of the IPv6 packet that carried the Binding Revocation
Indication. However, if one or more Alternate Care-of Address Indication. However, if one or more Alternate Care-of Address
options are included in addition to the mobile node identifier options are included in addition to the mobile node identifier
option, the local mobility anchor MUST revoke all mobile nodes option, the local mobility anchor MUST revoke all mobile nodes
bindings which proxy Care-of Address matches one of the Care-of bindings which proxy Care-of Address matches one of the Care-of
address(es) in the Alternate Care-of Address option(s). address(es) in the Alternate Care-of Address option(s).
o The local mobility anchor identifies all impacted mobile nodes o The local mobility anchor identifies all impacted mobile nodes
bindings and if the Acknowledgement (A) bit is set, the local bindings and if the Acknowledge (A) bit is set, the local mobility
mobility anchor MUST send a Binding Revocation Acknowledgement anchor MUST send a Binding Revocation Acknowledgement following
following Section 9.2.2 using the appropriate status code. Section 9.2.2 using the appropriate status code.
o If the Global (G) bit is NOT set, the local mobility anchor SHOULD o If the Global (G) bit is NOT set, the local mobility anchor SHOULD
use the included mobility options to identify the impacted mobile use the included mobility options to identify the impacted mobile
node binding as follows: node binding as follows:
1. If only the mobile node identifier, MN-ID, option is included, 1. If only the mobile node identifier, MN-ID, option is included,
the local mobility anchor MUST revoke all bindings for this the local mobility anchor MUST revoke all bindings for this
mobile node which use the specified mobile node NAI. mobile node which use the specified mobile node NAI.
2. If the mobile node identifier, MN-ID, and the Home Network 2. If the mobile node identifier, MN-ID, and the Home Network
skipping to change at page 30, line 22 skipping to change at page 30, line 30
multiple Home Network Prefixes for the specified mobile node multiple Home Network Prefixes for the specified mobile node
NAI. NAI.
The Revocation Trigger field value in the received Binding Revocation The Revocation Trigger field value in the received Binding Revocation
Indication could be used by the local mobility anchor to log an event Indication could be used by the local mobility anchor to log an event
or update some local parameters which tracks the state of the peer or update some local parameters which tracks the state of the peer
mobile access gateway. mobile access gateway.
9.2.2. Sending Binding Revocation Acknowledgement 9.2.2. Sending Binding Revocation Acknowledgement
When the local mobility anchor receive a valid Binding Revocation When the local mobility anchor receives a valid Binding Revocation
Indication with the (A) bit set and after processing the Binding Indication with the Acknowledge (A) bit set and after processing the
Revocation Indication message, the local mobility anchor sends a Binding Revocation Indication message, the local mobility anchor
packet to the mobile access gateway containing a Binding Revocation sends a packet to the mobile access gateway containing a Binding
Acknowledgement following the process in Section 7.1 and the Revocation Acknowledgement following the process in Section 7.1 and
following: the following:
o If the (P) bit was set in the received Binding Revocation o If the (P) bit was set in the received Binding Revocation
Indication, the local mobility anchor MUST set the (P) bit in the Indication, the local mobility anchor MUST set the (P) bit in the
Binding Revocation Acknowledgement. Binding Revocation Acknowledgement.
o If the Global (G) bit was set in the received Binding Revocation o If the Global (G) bit was set in the received Binding Revocation
Indication, the local mobility anchor MUST set the (G) bit in the Indication, the local mobility anchor MUST set the Global (G) bit
Binding Revocation Acknowledgement. in the Binding Revocation Acknowledgement.
o If the IPv4 HoA Binding Only (V) bit was set in the received o If the IPv4 HoA Binding Only (V) bit was set in the received
Binding Revocation Indication, the local mobility anchor MUST set Binding Revocation Indication, the local mobility anchor MUST set
the (V) bit in the Binding Revocation Acknowledgement. the (V) bit in the Binding Revocation Acknowledgement.
o The local mobility anchor MUST set the Status field to a valid o The local mobility anchor MUST set the Status field to a valid
code that reflects the processing of the received Binding code that reflects the processing of the received Binding
Revocation Indication. If the mobile access gateway is not Revocation Indication. If the mobile access gateway is not
authorized to use the Per-Peer Global revocation feature, the authorized to use the Per-Peer Global revocation feature, the
local mobility anchor MUST set the Status field to (Global local mobility anchor MUST set the Status field to (Global
Revocation NOT Authorized). Revocation NOT Authorized).
o In the case that one of the bindings identified in the received o In the case that one of the bindings identified in the received
Binding Revocation Indication message has already been released Binding Revocation Indication message has already been released,
before receiving the it, the local mobility anchor MAY set the the local mobility anchor MAY set the Status field to partial
Status field to partial success and in this case it MAY include success and in this case it MAY include the mobile node identifier
the mobile node identifier or the Home Network Prefix option to or the Home Network Prefix option to identify the binding(s) that
identify the binding(s) that failed revocation. failed revocation.
o The destination IP address of the IPv6 packet of the Binding o The destination IP address of the IPv6 packet of the Binding
Revocation Acknowledgement is set to the source IP address of the Revocation Acknowledgement is set to the source IP address of the
received Binding Revocation Indication. received Binding Revocation Indication.
10. Mobile Access Gateway Operation 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 Binding Revocation Indication MUST be formatted as in Section 6.1 o Binding Revocation Indication MUST be formatted as in Section 6.1
and the (P) bit is set. and the (P) bit is set.
o If the Acknowledgement (A) bit in the received Binding Revocation o If the Acknowledge (A) bit in the received Binding Revocation
Indication is set, the mobile access gateway MUST send a Binding Indication is set, the mobile access gateway MUST send a Binding
Revocation Acknowledgement following Section 10.1.2 using the Revocation Acknowledgement following Section 10.1.2 using the
appropriate status value. appropriate status value.
o If the Global (G) bit is set and the Revocation Trigger field o If the Global (G) bit is set and the Revocation Trigger field
value is "Per-Peer policy", the mobile access gateway identifies value is "Per-Peer policy", the mobile access gateway identifies
all bindings that are registered at the local mobility anchor and all bindings that are registered at the local mobility anchor and
hosted at the mobile access gateway. This Binding Revocation hosted at the mobile access gateway. This Binding Revocation
Indication does not include any other mobility options. In this Indication does not include any other mobility options. In this
case, the mobile access gateway MUST send a Binding Revocation case, the mobile access gateway MUST send a Binding Revocation
skipping to change at page 32, line 13 skipping to change at page 32, line 21
options are included in the Binding Revocation Indication message options are included in the Binding Revocation Indication message
or the mobile access gateway is not able to identify the impacted or the mobile access gateway is not able to identify the impacted
mobile nodes bindings based on the included mobility options, the mobile nodes bindings based on the included mobility options, the
mobile access gateway MUST treat this as an error scenario. In mobile access gateway MUST treat this as an error scenario. In
this case, the mobile access gateway SHOULD send a Binding this case, the mobile access gateway SHOULD send a Binding
Revocation Acknowledgement message with status "Revoked Mobile Revocation Acknowledgement message with status "Revoked Mobile
Nodes Identity Required". Nodes Identity Required".
o If the Revocation Trigger field value in the received Binding o If the Revocation Trigger field value in the received Binding
Revocation Indication message indicates inter-MAG handover, e.g., Revocation Indication message indicates inter-MAG handover, e.g.,
Inter-MAG Handover - Unknown, and the (A) bit is set, the mobile Inter-MAG Handover - Unknown, and the Acknowledge (A) bit is set,
access gateway use the mobility option(s) included in the Binding the mobile access gateway uses the mobility option(s) included in
Revocation Indication message to identify the mobile node binding. the Binding Revocation Indication message to identify the mobile
The mobile access gateway SHOULD validate that the mobile node is node binding. The mobile access gateway SHOULD validate that the
no longer attached to the mobile access gateway before sending a mobile node is no longer attached to the mobile access gateway
successful Binding Revocation Acknowledgement message to the local before sending a successful Binding Revocation Acknowledgement
mobility anchor. However, if the mobile access gateway verified message to the local mobility anchor. However, if the mobile
that the mobile node is still directly attached, the mobile access access gateway verified that the mobile node is still directly
gateway MUST set the status field in the Binding Revocation attached, the mobile access gateway MUST set the status field in
Acknowledgement to "Revocation failed - MN is Attached". the Binding Revocation Acknowledgement to "Revocation failed - MN
is Attached".
o If the IPv4 HoA Binding Only (V) bit in the received Binding o If the IPv4 HoA Binding Only (V) bit in the received Binding
Revocation Indication message is set, the mobile access gateway Revocation Indication message is set, the mobile access gateway
uses the MN-ID option to identify the mobile node binding entry in uses the MN-ID option to identify the mobile node binding entry in
the BUL. It MUST verify that the IPv4 address included in the the Binding Update List (BUL). It MUST verify that the IPv4
IPv4 Home Address option in the received Binding Revocation address included in the IPv4 Home Address option in the received
Indication is the same as the IPv4 proxy HoA that is assigned to Binding Revocation Indication is the same as the IPv4 proxy HoA
the mobile node. After the mobile access gateway successfully that is assigned to the mobile node. After the mobile access
validates the received IPv4 home address as the mobile node IPv4 gateway successfully validates the received IPv4 home address as
HoA, it MUST consider this as an indication to release the mobile the mobile node IPv4 HoA, it MUST consider this as an indication
node IPv4 proxy HoA binding to the mobile node current proxy CoA to release the mobile node IPv4 proxy HoA binding to the mobile
ONLY. Consequently, it MUST continue to maintain the mobile node node current proxy CoA ONLY. Consequently, it MUST continue to
IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA maintain the mobile node IPv6 proxy HoA or HNP binding to the
as part of the mobile node binding in the BUL entry and release current mobile node proxy CoA as part of the mobile node binding
all resources associated with the MN IPv4 proxy HoA binding to the in the BUL entry and release all resources associated with the MN
MN pCoA. In this case, the mobile access gateway MUST send a IPv4 proxy HoA binding to the MN pCoA. In this case, the mobile
Binding Revocation Acknowledgement message with the Status field access gateway MUST send a Binding Revocation Acknowledgement
is set to success. On the other hand, if the mobile access message with the Status field is set to success. On the other
gateway is able to identify the mobile node binding using the hand, if the mobile access gateway is able to identify the mobile
MN-ID but failed to identify the received IPv4 proxy HoA, it MUST node binding using the MN-ID but failed to identify the received
send a Binding Revocation Acknowledgement with Status field is set IPv4 proxy HoA, it MUST send a Binding Revocation Acknowledgement
to "Binding Does NOT Exist". with Status field is set to "Binding Does NOT Exist".
The Revocation Trigger field value in the received Binding Revocation The Revocation Trigger field value in the received Binding Revocation
Indication could be used by the mobile access gateway to define what Indication could be used by the mobile access gateway to define what
actions the mobile access gateway could do to inform the mobile node actions the mobile access gateway could do to inform the mobile node
that its IP connectivity to the current HNP has been terminated, that its IP connectivity to the current HNP has been terminated,
e.g., if the Revocation Trigger field is set to "Administrative e.g., if the Revocation Trigger field is set to "Administrative
Reason", the mobile access gateway may send a RA message after Reason", the mobile access gateway may send a RA message after
setting the Home Network Prefix valid lifetime to zero. setting the Home Network Prefix valid lifetime to zero.
10.1.2. Sending Binding Revocation Acknowledgement 10.1.2. Sending Binding Revocation Acknowledgement
When the mobile access gateway receive a valid Binding Revocation When the mobile access gateway receives a valid Binding Revocation
Indication with the (A) bit set and after processing it, the mobile Indication with the Acknowledge (A) bit set and after processing it,
access gateway sends a packet to the local mobility anchor containing the mobile access gateway sends a packet to the local mobility anchor
a Binding Revocation Acknowledgement according to the procedure in containing a Binding Revocation Acknowledgement according to the
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 Binding Revocation Acknowledgement if it is set in the received Binding
Revocation Indication. Revocation Indication.
o If the Global (G) bit was set in the received Binding Revocation o If the Global (G) bit was set in the received Binding Revocation
Indication, the mobile access gateway MUST set the (G) bit in the Indication, the mobile access gateway MUST set the Global (G) bit
Binding Revocation Acknowledgement. in the Binding Revocation Acknowledgement.
o If the IPv4 HoA Binding Only (V) bit was set in the received o If the IPv4 HoA Binding Only (V) bit was set in the received
Binding Revocation Indication, the mobile access gateway MUST set Binding Revocation Indication, the mobile access gateway MUST set
the (V) bit in the Binding Revocation Acknowledgement. the (V) bit in the Binding Revocation Acknowledgement.
o The mobile access gateway MUST set the Status field to a valid o The mobile access gateway MUST set the Status field to a valid
code that reflects the processing of the received Binding code that reflects the processing of the received Binding
Revocation Indication. Revocation Indication.
o In the case that one or more of the bindings identified in the o In the case that one or more of the bindings identified in the
skipping to change at page 34, line 9 skipping to change at page 34, line 19
The mobile access gateway could send a Binding Revocation Indication The mobile access gateway could send a Binding Revocation Indication
message to indicate the termination of multiple mobile node bindings, message to indicate the termination of multiple mobile node bindings,
e.g., when using the global revocation with the Global (G) bit set. e.g., when using the global revocation with the Global (G) bit set.
In this case when an event occurs which requires the mobile access In this case when an event occurs which requires the mobile access
gateway to inform the local mobility anchor to terminate all mobile gateway to inform the local mobility anchor to terminate all mobile
nodes bindings which are registered at the local mobility anchor and nodes bindings which are registered at the local mobility anchor and
the mobile access gateway, the mobile access gateway sends a Binding the mobile access gateway, the mobile access gateway sends a Binding
Revocation Indication message following Section 7.1 and the Revocation Indication message following Section 7.1 and the
following: following:
o The Acknowledge (A) bit MUST be set in the to request the local o The Acknowledge (A) bit MUST be set to request the local mobility
mobility anchor to send a Binding Revocation Acknowledgement upon anchor to send a Binding Revocation Acknowledgement upon receipt
receipt of the Binding Revocation Indication. of the Binding Revocation Indication.
o The Proxy Binding (P) bit MUST be set to indicate that bindings o The Proxy Binding (P) bit MUST be set to indicate that bindings
that being revoked is a PMIPv6 binding. that being revoked is a PMIPv6 binding.
o The Global (G) bit MUST be set and the Revocation Trigger MUST o The Global (G) bit MUST be set and the Revocation Trigger MUST
contain a value of "Per-Peer Policy" in the Binding Revocation contain a value of "Per-Peer Policy" in the Binding Revocation
Indication to request the local mobility anchor to remove all Per- Indication to request the local mobility anchor to remove all Per-
Peer bindings that are registered with the local mobility anchor Peer bindings that are registered with the local mobility anchor
and hosted at this mobile access gateway. In this case, the MN-ID and hosted at this mobile access gateway. In this case, the MN-ID
option MUST be included in the Binding Revocation Indication and option MUST be included in the Binding Revocation Indication and
contain the mobile access gateway identity. In addition, the contain the mobile access gateway identity. In addition, the
mobile access gateway MAY include one or more Alternate Care-of mobile access gateway MAY include one or more Alternate Care-of
Address option(s). The Alternate Care-of Address option(s) Address option(s). The Alternate Care-of Address option(s)
contain the proxy Care-of address(es) which their bindings are contain the proxy Care-of address(es) the bindings of which are
being impacted by this Binding Revocation Indication message. being impacted by this Binding Revocation Indication message.
o The mobile access gateway address MAY be used as the source o The mobile access gateway address MAY be used as the source
address in the packet's IPv6 header. address in the packet's IPv6 header.
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the local mobility anchor to return a Binding Revocation the local mobility anchor to return a Binding Revocation
Acknowledgement in response to this Binding Revocation Indication. Acknowledgement in response to this Binding Revocation Indication.
As described in Section 7.3, the mobile access gateway SHOULD As described in Section 7.3, the mobile access gateway SHOULD
retransmit this Binding Revocation Indication to the local mobility retransmit this Binding Revocation Indication to the local mobility
skipping to change at page 35, line 34 skipping to change at page 35, line 45
Upon receiving a packet carrying a Binding Revocation Indication, the Upon receiving a packet carrying a Binding Revocation Indication, the
mobile node MUST validate the packet according to Section 7.2 and the mobile node MUST validate the packet according to Section 7.2 and the
following tests: following tests:
o The mobile node MUST verify that the IP address in the Type 2 o The mobile node MUST verify that the IP address in the Type 2
routing header is its Home Address and that its Binding Update routing header is its Home Address and that its Binding Update
List contains an entry for that Home Address. If one of the List contains an entry for that Home Address. If one of the
tests, fails the mobile node SHOULD silently discard the received tests, fails the mobile node SHOULD silently discard the received
Binding Revocation Indication message. Binding Revocation Indication message.
o If the Acknowledgement (A) bit is set in the Binding Revocation o If the Acknowledge (A) bit is set in the Binding Revocation
Indication and its Binding Update List contains an entry for the Indication and its Binding Update List contains an entry for the
IP address in the Type 2 routing header, the mobile node MUST send IP address in the Type 2 routing header, the mobile node MUST send
a Binding Revocation Acknowledgement. However, in all other cases a Binding Revocation Acknowledgement. However, in all other cases
when the (A) bit is set in the BRI, the mobile node SHOULD send a when the Acknowledge (A) bit is set in the BRI, the mobile node
Binding Revocation Acknowledgement. In all cases, the mobile node SHOULD send a Binding Revocation Acknowledgement. In all cases,
MUST follow Section 11.2 and send a Binding Revocation the mobile node MUST follow Section 11.2 and send a Binding
Acknowledgement using the appropriate status code. Revocation Acknowledgement using the appropriate status code.
o If the IPv4 HoA Binding Only (V) bit is set in the received BRI o If the IPv4 HoA Binding Only (V) bit is set in the received BRI
message, the mobile node MUST verify that there is an IPv4 Home message, the mobile node MUST verify that there is an IPv4 Home
Address option in the received Binding Revocation Indication and Address option in the received Binding Revocation Indication and
the IPv4 address included in the IPv4 Home Address option is the the IPv4 address included in the IPv4 Home Address option is the
same as its IPv4 HoA that is assigned to the mobile node. If this same as its IPv4 HoA that is assigned to the mobile node. If this
verification is successful, the mobile node MUST consider this verification is successful, the mobile node MUST consider this
Binding Revocation Indication as an indication to release the Binding Revocation Indication as an indication to release the
mobile node IPv4 HoA binding ONLY to its current Care-of Address. mobile node IPv4 HoA binding ONLY to its current Care-of Address.
Consequently, the mobile node MUST continue to maintain its IPv6 Consequently, the mobile node MUST continue to maintain its IPv6
HoA binding to the current CoA as part of the mobile node binding HoA binding to the current CoA as part of the mobile node binding
in the BUL entry and release all resources associated with the MN in the BUL entry and release all resources associated with the MN
IPv4 HoA binding. In this case, the mobile node MUST send a IPv4 HoA binding. In this case, the mobile node MUST send a
Binding Revocation Acknowledgement message with the Status field Binding Revocation Acknowledgement message with the Status field
is set to "success". On the other hand, if the IPv4 Home Address is set to "success". On the other hand, if the IPv4 Home Address
Option was NOT included in the received BRI with the (V) bit set, Option was NOT included in the received BRI with the (V) bit set,
the MN SHOULD send a Binding Revocation Acknowledgement message the MN SHOULD send a Binding Revocation Acknowledgement message
with the Status field set to "IPv4 Home Address Option Required". with the Status field set to "IPv4 Home Address Option Required".
Additionally, if the IPv4 HoA received in the IPv4 Home Address Additionally, if the IPv4 HoA received in the IPv4 Home Address
skipping to change at page 40, line 26 skipping to change at page 40, line 36
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[ID-PMIP6-IPv4] [ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-10 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-14
(work in progress), March 2009. (work in progress), July 2009.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration", "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-12 (work in progress), draft-ietf-monami6-multiplecoa-14 (work in progress),
March 2009. May 2009.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009. Routers", RFC 5555, June 2009.
16.2. Informative References 16.2. Informative References
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
skipping to change at page 41, line 32 skipping to change at page 41, line 35
Sri Gundavelli Sri Gundavelli
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
Kuntal Chowdhury Kuntal Chowdhury
Startent Networks Starent Networks
30 International Place 30 International Place
Tewksbury, MA 01876 Tewksbury, MA 01876
USA USA
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
 End of changes. 46 change blocks. 
154 lines changed or deleted 159 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/