draft-ietf-mext-binding-revocation-04.txt   draft-ietf-mext-binding-revocation-05.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: September 25, 2009 S. Gundavelli Expires: October 1, 2009 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
March 24, 2009 March 30, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-04.txt draft-ietf-mext-binding-revocation-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 25, 2009. This Internet-Draft will expire on October 1, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding
Revocation . . . . . . . . . . . . . . . . . . . . . . 8 Revocation . . . . . . . . . . . . . . . . . . . . . . 8
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 9 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 9
4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Binding Revocation Messages over IPv4 Transport Network . . . 10 5. Binding Revocation Messages over IPv4 Transport Network . . . 10
6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10
6.1. Binding Revocation Indication Message . . . . . . . . . . 11 6.1. Binding Revocation Indication Message . . . . . . . . . . 11
6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14
7. Binding Revocation Process Considerations . . . . . . . . . . 17 7. Binding Revocation Process Considerations . . . . . . . . . . 17
7.1. Sending Binding Revocation Messages . . . . . . . . . . . 17 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 17
7.2. Receiving Binding Revocation Messages . . . . . . . . . . 18 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 17
7.3. Retransmission of Binding Revocation Indication . . . . . 19 7.3. Retransmission of Binding Revocation Indication . . . . . 18
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 19
8.1. Sending Binding Revocation Indication . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . 21 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 20
9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 21 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 20
9.1.1. Sending Binding Revocation Indication . . . . . . . . 21 9.1.1. Sending Binding Revocation Indication . . . . . . . . 20
9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23
9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 24 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 24
9.2.1. Receiving Binding Revocation Indication . . . . . . . 24 9.2.1. Receiving Binding Revocation Indication . . . . . . . 24
9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 25 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 25
10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 26
10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 26
10.1.1. Receiving Binding Revocation Indication . . . . . . . 26 10.1.1. Receiving Binding Revocation Indication . . . . . . . 26
10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 28 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 27
10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 29 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 28
10.2.1. Sending Binding Revocation Indication . . . . . . . . 29 10.2.1. Sending Binding Revocation Indication . . . . . . . . 28
10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 29 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 29
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 30 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 30
11.1. Receiving Binding Revocation Indication . . . . . . . . . 30 11.1. Receiving Binding Revocation Indication . . . . . . . . . 30
11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 32 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 31
12. Protocol Configuration Variables . . . . . . . . . . . . . . . 32 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 31
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
14. Security Considerations . . . . . . . . . . . . . . . . . . . 34 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34
16.2. Informative References . . . . . . . . . . . . . . . . . . 35 16.2. Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
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
skipping to change at page 4, line 47 skipping to change at page 4, line 47
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Terminology 2.2. Terminology
All the general mobility related terminology and abbreviations are to All the general mobility related terminology and abbreviations are to
be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile be interpreted as defined in Mobile IPv6 [RFC3775] and Proxy Mobile
IPv6 [RFC5213] specifications. IPv6 [RFC5213] specifications.
3. Binding Revocation Protocol and Use Cases Overview 3. Binding Revocation Protocol and Use Cases Overview
This specification specifies a binding revocation mechanism where a This specification specifies a generic binding revocation mechanism
mobility node can communicate to the mobile node or another mobility where a mobility node can communicate to the mobile node or another
node the termination of the mobile node registration binding. The mobility node the identity of the the mobile node registration
following subsections describe the protocol overview and applicable binding that is being terminated. In the case when this mechanism is
use cases. used for bulk termination or multiple bindings, the identities of
these bindings are communicated to the mobile node or mobility node
using the same generic mechanism. The following subsections describe
the protocol overview and applicable use cases.
3.1. Binding Revocation Protocol 3.1. Binding Revocation Protocol
In the case of Mobile IPv6, if the home network decides to terminate In the case of Mobile IPv6, if the home network decides to terminate
the service of the mobile node, the home agent sends a Binding the service of the mobile node, the home agent sends a Binding
Revocation Indication (BRI) message to the mobile node. The home Revocation Indication (BRI) message to the mobile node. The home
agent includes the HoA in the Type 2 routing header as specified in agent includes the HoA in the Type 2 routing header as specified in
[RFC3775] to indicate the impacted mobile node binding. In the case [RFC3775] to indicate the impacted mobile node binding. In the case
of DSMIPv6 [ID-DSMIP6], the home agent may include the IPv4 Home of DSMIPv6 [ID-DSMIP6], the home agent may include the IPv4 Home
Address Option with the mobile node assigned home IPv4 address. Address Option with the mobile node assigned home IPv4 address.
skipping to change at page 5, line 45 skipping to change at page 5, line 48
sending a Proxy BU with a lifetime of zero to indicate to the LMA of sending a Proxy BU with a lifetime of zero to indicate to the LMA of
the termination of the PMIPv6 mobile node binding registration. In the termination of the PMIPv6 mobile node binding registration. In
this case, the MAG includes the MN HNP option, the MN-ID option and this case, the MAG includes the MN HNP option, the MN-ID option and
all other required mobility options as per [RFC5213] in order for the all other required mobility options as per [RFC5213] in order for the
LMA to identify the mobile node PMIPv6 binding. Additionally, in the LMA to identify the mobile node PMIPv6 binding. Additionally, in the
case when the mobility access gateway communicates a bulk termination case when the mobility access gateway communicates a bulk termination
of PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A) of PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A)
bits set and includes the MAG identity in the MN-ID option. When the bits set and includes the MAG identity in the MN-ID option. When the
LMA receives such BRI message, it ensures that the mobility access LMA receives such BRI message, it ensures that the mobility access
gateway is authorized to send such bulk termination message and then gateway is authorized to send such bulk termination message and then
process the BRI message accordingly. If the local mobility anchor processes the BRI message accordingly. If the local mobility anchor
processes the BRI message successfully, the LMA responds to the processes the BRI message successfully, the LMA responds to the
mobile access gateway by sending the BRA message. mobile access gateway by sending the BRA message.
In any of the above cases, the initiator of the binding revocation In any of the above cases, the initiator of the binding revocation
procedure, e.g., HA, LMA, MAG, uses the Revocation Trigger field in procedure, e.g., HA, LMA, MAG, uses the Revocation Trigger field in
the Binding Revocation Indication message to indicate to the the Binding Revocation Indication message to indicate to the
receiving node the reason for initiating the revocation procedure. receiving node the reason for initiating the revocation procedure.
3.2. MIPv6 and DSMIP6 Use Case 3.2. MIPv6 and DSMIP6 Use Case
skipping to change at page 7, line 30 skipping to change at page 7, line 30
illustrates the message flow when the HA revokes two registered illustrates the message flow when the HA revokes two registered
Care-of addresses for the same MN in a single BRI message. Care-of addresses for the same MN in a single BRI message.
HA Binding Cache HA Binding Cache
================ ================
MN-BID1 [CoA1+HoA] MN-BID1 [CoA1+HoA]
MN HA MN-BID2 [CoA2+HoA] MN HA MN-BID2 [CoA2+HoA]
| | MN-BID3 [CoA3+HoA] | | MN-BID3 [CoA3+HoA]
| | MN-BID4 [CoA4+HoA] | | MN-BID4 [CoA4+HoA]
| HoA in Type 2 Hdr | | HoA in Type 2 Hdr |
|<----------------- + --------------------| |<<<<-------------- + ---------------------|
| BRI [seq.#, A bit, BID1, BID4] | | BRI [seq.#, A bit, R. Trigger, BID1, BID4] |
| | | |
| | | |
| BRA (HoA in Dest. Option) [seq.#, Status] | | BRA (HoA in Dest. Option) [seq.#, Status] |
|------------------------------------------>| |---------------------------------------->>>>|
| | | |
| | | |
Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings Figure 2: Home Agent Revokes MN's Specific Care-of Addresses Bindings
Additionally, the home agent may revoke all of the mobile node Additionally, the home agent may revoke all of the mobile node
registered bindings, by sending a BRI message without including any registered bindings, by sending a BRI message without including any
BID options while the HoA is included in the Type 2 routing header. BID options while the HoA is included in the Type 2 routing header.
Figure 1 illustrates the message flow when the home agent revokes all Figure 1 illustrates the message flow when the home agent revokes all
registered Care-of addresses bindings for a MN in a single BRI registered Care-of addresses bindings for a MN in a single BRI
skipping to change at page 8, line 36 skipping to change at page 8, line 36
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 identifies the respected binding and if the (A) bit was set in MAG identifies 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 the 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 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 handover. During the inter-MAG handover, 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.
inter-MAG handoff - same Access Types, to the source MAG in order to inter-MAG handocer - same Access Types, to the source MAG in order to
clean up the applicable resources reserved for the specified MN clean up the applicable resources reserved for the specified MN
binding. The MAG acknowledges the BRI message by sending a BRA binding. The MAG acknowledges the BRI message by sending a BRA
message to indicate the success or failure of the termination of the message to indicate the success or failure of the termination of the
mobile node binding. mobile node binding.
The process identified above can also be used by the LMA in scenarios The process identified above can also be used by the LMA in scenarios
other than the inter-MAG handoff with the proper revocation trigger other than the inter-MAG handover with the proper revocation trigger
value to indicate to the peer MAG that a specific proxy mobile IPv6 value to indicate to the peer MAG that a specific proxy mobile IPv6
binding or bindings have been revoked. binding or bindings have been revoked.
oldMAG newMAG LMA oldMAG newMAG LMA
| | | | | |
| | PBU | | | PBU |
| |--------------------------->| | |--------------------------->|
| | PBU triggers | | PBU triggers
| | BRI Msg to oldMAG | | BRI Msg to oldMAG
| | | | | |
skipping to change at page 9, line 27 skipping to change at page 9, line 27
|<-----------------------------------------| |<-----------------------------------------|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| BRA [seq.#, Status, P bit] | | BRA [seq.#, Status, P bit] |
|----------------------------------------->| |----------------------------------------->|
| | | | | |
| | | | | |
Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff Figure 3: LMA Revokes a MN Registration During Inter-MAG Handover
In addition, the LMA can send a BRI message to indicate that all In addition, the LMA can send a BRI message to indicate that all
bindings which are hosted by the peer MAG and registered with the LMA bindings which are hosted by the peer MAG and registered with the LMA
are being revoked by setting the (G) bit as described in are being revoked by setting the (G) bit as described in
Section 9.1.1. Section 9.1.1.
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings
The mobile access gateway sends a BRI message with the (G) bit is set The mobile access gateway sends a BRI message with the (G) bit is set
to indicate that all mobility bindings which are registered at the to indicate that all mobility bindings which are registered at the
skipping to change at page 11, line 33 skipping to change at page 11, line 33
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. In this
in Section 6.1 or BRA as in Section 6.2. specification, it is either a BRI as 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
Revocation Message which has a MH type <IANA-TBD> and a Binding Revocation Message which has a MH type <IANA-TBD> and a Binding
Revocation Type value of 1. It is used by the revoking mobility node Revocation Type value of 1. It is used by the revoking mobility node
to inform the receiving mobility entity that the IP mobility service to inform the receiving mobility entity of the identity of a specific
of a specific binding or bindings have been revoked. Binding binding or bindings which IP mobility service have been revoked.
Revocation Indication message is sent as described in Section 8.1, Binding Revocation Indication message is sent as described in
Section 9.1.1, and Section 10.2.1. Section 8.1, Section 9.1.1, and Section 10.2.1.
When the value 1 is indicated in the B. R. type field of the Binding When the value 1 is indicated in the B. R. type field of the Binding
Revocation Message, the format of the Binding Revocation Message Data Revocation Message, the format of the Binding Revocation Message Data
follows the Binding Revocation Indication message as in Figure 5 follows the Binding Revocation Indication message as in Figure 5
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 1 | R. Trigger | | B.R. Type = 1 | R. Trigger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |A|P|V|G| Reserved | | Sequence # |A|P|V|G| Reserved |
skipping to change at page 12, line 23 skipping to change at page 12, line 23
. Mobility options . . Mobility options .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Binding Revocation Indication Message Figure 5: Binding Revocation Indication Message
Revocation Trigger Revocation Trigger
8-bit unsigned integer indicating the event which triggered the 8-bit unsigned integer indicating the event which triggered the
revoking node to send the BRI message. The Reserved and Per-MN revoking node to send the BRI message. The Reserved and Per-MN
Revocation Triggers value are less than 128. The per-MN Revocation Triggers value are less than 128 except the reserved
revocation triggers is used when the BRI message intends to revoke values 250-255. The per-MN revocation triggers is used when the
one or more bindings for the same mobile node. The Global BRI message intends to revoke one or more bindings for the same
Revocation Trigger values are greater than 128 and used in the BRI mobile node. The Global Revocation Trigger values are greater
message with the (G) bit is set for for global revocation. The than 128 and less than 250 and used in the BRI message with the
following Revocation Trigger values are currently defined: (G) bit set for global revocation. The following Revocation
Trigger values are currently defined:
Reserved and Per-MN Revocation Trigger: Reserved and Per-MN Revocation Trigger:
0 Reserved 0 Reserved
1 Unspecified 1 Unspecified
2 Administrative Reason 2 Administrative Reason
3 Inter-MAG Handoff - same Access Types 3 Inter-MAG Handover
4 Inter-MAG Handoff - different Access Types 4 User Initiated Session(s) Termination
5 Inter-MAG - Unknown Handoff 5 Access Network Session(s) Termination
6 User Initiated Session(s) Termination 6 Possible Out-of Sync BCE State
7 Access Network Session(s) Termination
8 IPv4 HoA Lease Expires
9 Possible Out-of Sync BCE State
250-255 Reserved For Testing Purposes only 250-255 Reserved For Testing Purposes only
All other values are Reserved All other values are Reserved
Global Revocation Trigger: Global Revocation Trigger:
128 Per-Peer Policy 128 Per-Peer Policy
129 Revoking Mobility Node Local Policy 129 Revoking Mobility Node Local Policy
Sequence # Sequence #
A 16-bit unsigned integer used by the sending mobility node to A 16-bit unsigned integer used by the sending mobility node to
match a returned Binding Revocation Acknowledgement with this match a returned Binding Revocation Acknowledgement with this
Binding Revocation Indication. It could be a random number. Binding Revocation Indication. It could be a random number.
Acknowledge (A) Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobility node, e.g. The Acknowledge (A) bit is set by the sending mobility node, e.g.
LMA, HA, or MAG, to request a Binding Revocation Acknowledgement LMA, HA, or MAG, to request a Binding Revocation Acknowledgement
skipping to change at page 14, line 19 skipping to change at page 14, line 16
o Home Network Prefix option [RFC5213]. This option MAY be used o Home Network Prefix option [RFC5213]. This option MAY be used
when the (P) bit is set. This option MUST be present when the BRI when the (P) bit is set. This option MUST be present when the BRI
is used to revoke a single PMIP binding cache entry. is used to revoke a single PMIP binding cache entry.
o Mobile Node Identifier Option [RFC4283]. This option is mandatory o Mobile Node Identifier Option [RFC4283]. This option is mandatory
when the (P) bit is set. Additionally, if the (G) bit is set by when the (P) bit is set. Additionally, if the (G) bit is set by
the mobile access gateway, this option carries the MAG identity. the mobile access gateway, this option carries the MAG identity.
o Binding ID mobility option [ID-MCoA]. This option is mandatory if o Binding 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 requests 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]. This option is included only when the IPv4 address [ID-DSMIP6]. This option is included only when the IPv4
HoA Binding only (V) bit is set. HoA Binding only (V) bit is set.
o Alternate Care-of Address mobility option [RFC3775]. This option o Alternate Care-of Address mobility option [RFC3775]. This option
MAY be included to indicate the Care-of Address of the mobile MAY be included to indicate the Care-of Address of the mobile
skipping to change at page 15, line 36 skipping to change at page 15, line 34
entity. Values of the Status field less than 128 indicate that entity. Values of the Status field less than 128 indicate that
the Binding Revocation Indication was processed successfully by the Binding Revocation Indication was processed successfully by
the receiving node. Values greater than or equal to 128 indicate the receiving node. Values greater than or equal to 128 indicate
that the Binding Revocation Indication was rejected by the that the Binding Revocation Indication was rejected by the
receiving node. The following status values are currently receiving node. The following status values are currently
defined: defined:
0 success 0 success
1 partial success 1 partial success
128 Binding Does NOT Exist 128 Binding Does NOT Exist
129 IPv4 HoA Binding Does NOT Exist 129 IPv4 Home Address Option Required
130 IPv4 Home Address Option Required 130 Global Revocation NOT Authorized
131 Global Revocation NOT Authorized 131 Revoked Mobile Nodes Identity Required
132 CAN NOT Identify Binding 132 Revocation Failed - MN is Attached
133 Revocation Failed - MN is Attached 133 Revocation Trigger NOT Supported
134 Revocation Trigger NOT Supported 134 Revocation Function NOT Supported
135 Revocation Function NOT Supported
Sequence # Sequence #
The sequence number in the Binding Revocation Acknowledgement is The sequence number in the Binding Revocation Acknowledgement is
copied from the Sequence Number field in the Binding Revocation copied from the Sequence Number field in the Binding Revocation
Indication. It is used by the revoking mobility entity, e.g. HA, Indication. It is used by the revoking mobility entity, e.g. HA,
LMA, MAG, in matching this Binding Revocation Acknowledgement with LMA, MAG, in matching this Binding Revocation Acknowledgement with
the outstanding BRI. the outstanding BRI.
Proxy Binding (P) Proxy Binding (P)
skipping to change at page 17, line 30 skipping to change at page 17, line 22
When sending a Binding Revocation message, the sending mobility node, When sending a Binding Revocation message, the sending mobility node,
initiator, constructs the packet as it would any other Mobility initiator, constructs the packet as it would any other Mobility
Header with the exception of setting the MH Type field to <IANA-TBD>. Header with the exception of setting the MH Type field to <IANA-TBD>.
The mobility entity which initiates the revocation process MUST use The mobility entity which initiates the revocation process MUST use
the underlying security association, e.g., IPsec SA, that has been the underlying security association, e.g., IPsec SA, that has been
used to secure the mobile node binding registration signaling in used to secure the mobile node binding registration signaling in
securing the BRI and BRA messages transmission with the responding securing the BRI and BRA messages transmission with the responding
mobility entity. mobility entity.
When a mobility entity initiate the binding revocation process by When a mobility entity initiates the binding revocation process by
sending a Binding Revocation Indication message, the initiator MUST sending a Binding Revocation Indication message, the initiator MUST
construct the BRI message as described in Section 6.1. In the BRI construct the BRI message as described in Section 6.1. In the BRI
message, the initiator MUST set the Sequence Number field to the next message, the initiator MUST set the Sequence Number field to the next
sequence number available for Binding Revocation. Since sending BRI sequence number available for Binding Revocation. Since sending BRI
messages is not done on a regular basis, a 16 bit sequence number messages is not done on a regular basis, a 16 bit sequence number
field is large enough to allow the initiator to match the BRA to the field is large enough to allow the initiator to match the BRA to the
outstanding BRI with (A) bit set using the sequence number field outstanding BRI with (A) bit set using the sequence number field
only. only.
However, when the responder acknowledges the BRI message by sending a However, when the responder acknowledges the BRI message by sending a
skipping to change at page 20, line 31 skipping to change at page 20, line 23
the reason for sending the Binding Revocation Indication message and the reason for sending the Binding Revocation Indication message and
its local policy. In this case, if the home agent accepts the BU, it its local policy. In this case, if the home agent accepts the BU, it
needs to update the mobile node BCE accordingly, e.g. removing the needs to update the mobile node BCE accordingly, e.g. removing the
revocation in progress flag. 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 SHOULD NOT include
of the Binding ID options. any of the Binding ID options.
8.2. Receiving Binding Revocation Acknowledgement 8.2. Receiving Binding Revocation Acknowledgement
When the home agent receives a packet carrying a valid BRA that was When the home agent receives a packet carrying a valid BRA that was
successfully processed as in Section 7.2, the home agent SHOULD successfully processed as in Section 7.2, the home agent 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 home agent deletes the Indication was processed successfully, the home agent deletes the
MINDelayBRIs timer and the mobile node bindings and all related MINDelayBRIs timer and the mobile node bindings and all related
skipping to change at page 22, line 5 skipping to change at page 21, line 42
Binding Update during the mobile node registration. Binding Update during the mobile node registration.
o If the Mobile Node Identifier, MN-ID, is registered in more than o If the Mobile Node Identifier, MN-ID, is registered in more than
one of the mobile node's BCE and the LMA does NOT need to revoke one of the mobile node's BCE and the LMA does NOT need to revoke
all of the mobile node's bindings, the packet MUST contain another all of the mobile node's bindings, the packet MUST contain another
identifier to uniquely identify the mobile node binding(s) that is identifier to uniquely identify the mobile node binding(s) that is
being revoked, e.g., at least one Home Network Prefix option which 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 MUST be used as the
address in the packet's IPv6 header, unless an Alternate Care-of destination address in the packet's IPv6 header, unless an
Address mobility option is included in the Binding Revocation Alternate Care-of Address mobility option is included in the
Indication message. Binding Revocation Indication message.
The Acknowledge (A) bit in the Binding Revocation Indication requests The Acknowledge (A) bit in the Binding Revocation Indication requests
the mobile access gateway to return a Binding Revocation the mobile access gateway to return a Binding Revocation
Acknowledgement in response to this Binding Revocation Indication. Acknowledgement 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
skipping to change at page 22, line 30 skipping to change at page 22, line 20
When the local mobility anchor sends a Binding Revocation Indication When the local mobility anchor sends a Binding Revocation Indication
to the mobile access gateway to remove a specific binding and the to the mobile access gateway to remove a specific binding and the
Acknowledge (A) bit is set in the BRI, the local mobility anchor sets Acknowledge (A) bit is set in the BRI, the local mobility anchor sets
a flag in the mobile node proxy BCE to indicate that revocation is in a flag in the mobile node proxy BCE to indicate that revocation is in
progress and starts the MINDelayBRIs timer. The local mobility progress and starts the MINDelayBRIs timer. The local mobility
anchor SHOULD maintain the mobile node proxy BCE in this state until anchor SHOULD maintain the mobile node proxy BCE in this state until
it receives a Binding Revocation Acknowledgement or the it receives a Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached. In the case when the local BRIMaxRetransmitNumber is reached. In the case when the local
mobility anchor sets the Revocation Trigger field to a value which mobility anchor sets the Revocation Trigger field to a value which
indicate inter-MAG handover, the local mobility anchor MAY switch the indicates inter-MAG handover, the local mobility anchor MAY switch
mobile node IP tunnel to the target mobile access gateway before the 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 source mobile access
gateway. gateway.
In a race condition case, the local mobility anchor may receive a PBU In a race condition case, the local mobility anchor may receive a PBU
from the mobile access gateway while the mobile node's proxy BCE has 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 the revocation in progress flag set, the LMA should handle this case
based on the reason for sending the Binding Revocation Indication based on the reason for sending the Binding Revocation Indication
message and its local policy. In this case, if the LMA accepts the 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. PBU, it needs to update the mobile node proxy BCE accordingly, e.g.
removing the revocation in progress flag. removing the revocation in progress flag.
skipping to change at page 23, line 42 skipping to change at page 23, line 32
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 IPv4 Home Address option MUST be included with the mobile o The IPv4 Home Address option MUST be included with the mobile
node's registered IPv4 home address that is being released in node's registered IPv4 home address that is being released in
addition to the MN-ID option. addition to the MN-ID option.
o The mobile node Home Network Prefix option MUST NOT be included. o The mobile node Home Network Prefix option MUST NOT be included.
o The Revocation Trigger field MUST be set to an appropriate value, o The Revocation Trigger field MUST be set to an appropriate value,
e.g. "IPv4 Address Lease Expired". e.g. "User Initiated Session(s) Termination".
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 25, line 6 skipping to change at page 24, line 43
"Per-Peer Policy", and only the mobile node identifier, MN-ID, "Per-Peer Policy", and only the mobile node identifier, MN-ID,
option is included, the local mobility anchor MUST revoke all option is included, the local mobility anchor MUST revoke all
mobile nodes bindings which proxy CoA is the one used as the mobile nodes bindings which proxy CoA is the one used as the
source of the IPv6 packet that carried the BRI. However, if one source of the IPv6 packet that carried the BRI. However, if one
or more Alternate Care-of Address options are included in addition or more Alternate Care-of Address options are included in addition
to the mobile node identifier option in the BRI message, the local to the mobile node identifier option in the BRI message, the local
mobility anchor MUST revoke all mobile nodes bindings which proxy mobility anchor MUST revoke all mobile nodes bindings which proxy
Care-of Address matches one of the Care-of address(es) in the Care-of Address matches one of the Care-of address(es) in the
Alternate Care-of Address option(s). Alternate Care-of Address option(s).
o If the Global (G) bit is set and the Revocation Trigger value is
"Per-Peer Policy", and the mobile node identifier, MN-ID, option
is NOT included, the local mobility anchor MUST reject the BRI
message by sending a BRA message with the status field is set to
"Global Revocation Authorization Required".
o The LMA identifies all impacted mobile nodes bindings and if the 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 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,
skipping to change at page 26, line 46 skipping to change at page 26, line 32
mobile access gateway MUST validate the packet according to mobile access gateway MUST validate the packet according to
Section 7.2 and the following: Section 7.2 and the following:
o BRI MUST be formatted as in Section 6.1 and the (P) bit is set. o BRI MUST be formatted as in Section 6.1 and the (P) bit is set.
o If the Acknowledgement (A) bit in the received BRI is set, the o If the Acknowledgement (A) bit in the received 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
set to "Per-Peer policy", the mobile access gateway identifies all value is "Per-Peer policy", the mobile access gateway identifies
bindings that are registered at the LMA and hosted at the MAG. all 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. In this case, the MAG MUST send a BRA with the mobility options. 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
set to "Revoking Mobility Node Local Policy", the MAG MUST value is "Revoking Mobility Node Local Policy", the MAG MUST
identify all bindings that are registered at the LMA and hosted at identify all bindings that are registered at the LMA and hosted at
the MAG using the mobility option(s) included in the BRI. This the MAG using the mobility option(s) included in the BRI. This
Binding Revocation Indication SHOULD include at least the MN-ID Binding Revocation Indication SHOULD include at least the MN-ID
option, e.g. with a wild card NAI. In this case, the MAG MUST option, e.g. with a wild card NAI. In this case, the MAG MUST
send a BRA with the appropriate status code to the LMA. send a BRA with the 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
set to "Revoking Mobility Node Local Policy", and no mobility value is "Revoking Mobility Node Local Policy", and no mobility
options are included in the Binding Revocation Indication message options are included in the Binding Revocation Indication message
or the MAG is not able to identify the impacted mobile nodes or the MAG is not able to identify the impacted mobile nodes
bindings based on the included mobility options, the MAG MUST bindings based on the included mobility options, the MAG MUST
treat this as an error scenario. In this case, the MAG SHOULD treat this as an error scenario. In this case, the MAG SHOULD
send a Binding Revocation Acknowledgement message with status "CAN send a Binding Revocation Acknowledgement message with status
NOT Identify Binding". "Revoked Mobile Nodes Identity Required".
o If the Revocation Trigger field value in the received Binding o If the Revocation Trigger field value in the received Binding
Revocation Indication message indicates an inter-MAG handover and Revocation Indication message is "Inter-MAG Handover" and the (A)
the (A) bit is set, the MAG use the mobility option(s) included in bit is set, the MAG use the mobility option(s) included in the BRI
the BRI message to identify the mobile node binding. The mobile message to identify the mobile node binding. The mobile access
access gateway MAY validate that the mobile node is no longer gateway SHOULD validate that the mobile node is no longer attached
attached to the mobile access gateway before sending a successful to the mobile access gateway before sending a successful Binding
Binding Revocation Acknowledgement message to the LMA. However, Revocation Acknowledgement message to the LMA. However, if the
if the Revocation Trigger field is set to "Inter-MAG - Unknown MAG verified that the MN is still attached, the MAG MUST set the
Handoff" or "Possible Out-of Sync BCE State" and the (A) bit is status field in the BRA to "Revocation failed - MN is Attached".
set, the MAG MUST validate that the mobile node is no longer
attached to the MAG before sending a 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 IPv4 HoA Binding Only (V) bit in the received BRI message o If the IPv4 HoA Binding Only (V) bit in the received BRI message
is set, the MAG uses the MN-ID option to identify the mobile node is set, the MAG uses the MN-ID option to identify the mobile node
binding entry in the BUL. The MAG MUST verify that the IPv4 binding entry in the BUL. The MAG MUST verify that the IPv4
address included in the IPv4 Home Address option in the received address included in the IPv4 Home Address option in the received
BRI is the same as the IPv4 proxy HoA that is assigned to the BRI is the same as the IPv4 proxy HoA that is assigned to the
mobile node. After the MAG successfully validates the received mobile node. After the MAG successfully validates the received
IPv4 home address as the mobile node IPv4 HoA, the MAG MUST IPv4 home address as the mobile node IPv4 HoA, the MAG MUST
consider this as an indication to release the mobile node IPv4 consider this as an indication to release the mobile node IPv4
proxy HoA binding to the mobile node current proxy CoA ONLY. proxy HoA binding to the mobile node current proxy CoA ONLY.
Consequently, the MAG MUST continue to maintain the mobile node Consequently, the MAG MUST continue to maintain the mobile node
IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA IPv6 proxy HoA or HNP binding to the current mobile node proxy CoA
as part of the mobile node binding in the BUL entry and release as part of the mobile node binding in the BUL entry and release
all resources associated with the MN IPv4 proxy HoA binding to the all resources associated with the MN IPv4 proxy HoA binding to the
MN pCoA. In this case, the MAG MUST send a BRA message with the MN pCoA. In this case, the MAG MUST send a BRA message with the
status field is set to success. On the other hand, if the MAG is status field is set to success. On the other hand, if the MAG is
able to identify the mobile node binding using the MN-ID but able to identify the mobile node binding using the MN-ID but
failed to identify the received IPv4 proxy HoA, the MAG MUST send failed to identify the received IPv4 proxy HoA, the MAG MUST send
a BRA with status field is set to "IPv4 HoA Binding Does NOT a BRA with status field is set to "Binding Does NOT Exist".
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
skipping to change at page 28, line 42 skipping to change at page 28, line 23
the mobile access gateway MUST set the (V) bit in the Binding the mobile access gateway MUST set the (V) bit in the Binding
Revocation Acknowledgement. Revocation Acknowledgement.
o The mobile access gateway MUST set the status field to a valid o The mobile access gateway MUST set the status field to a valid
code that reflects the processing of the received Binding code that reflects the processing of the received Binding
Revocation Indication. Revocation Indication.
o In the case that one or more of the bindings identified in the o In the case that one or more of the bindings identified in the
received BRI message has already been released before receiving received BRI message has already been released before receiving
the BRI, the mobile access gateway MAY set the status field to the BRI, the mobile access gateway MAY set the status field to
partial success and in this case it MAY include the mobile node "partial success" and include the mobile node identifier, MN-ID,
identifier, MN-ID, or the Home Network Prefix option to identify or the Home Network Prefix option to identify the binding(s) that
the binding(s) that failed to be removed as part of the revocation 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
10.2.1. Sending Binding Revocation Indication 10.2.1. Sending Binding Revocation Indication
The mobile access gateway could send a Binding Revocation Indication The mobile access gateway could send a Binding Revocation Indication
skipping to change at page 29, line 22 skipping to change at page 28, line 48
In this case when an event occurs which requires the mobile access In this case when an event occurs which requires the mobile access
gateway to inform the LMA to terminate all mobile nodes bindings that gateway to inform the LMA to terminate all mobile nodes bindings that
are registered at the local mobility anchor and the mobile access are registered at the local mobility anchor and the mobile access
gateway, the mobile access gateway sends a Binding Revocation gateway, the mobile access gateway sends a Binding Revocation
Indication message following Section 7.1 and the following: Indication message following Section 7.1 and the following:
o The Acknowledge (A) bit MUST be set in the Binding Revocation o The Acknowledge (A) bit MUST be set in the Binding Revocation
Indication to request the local mobility anchor to send a Binding Indication to request the local mobility anchor 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 Binding Revocation o The Proxy Binding (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 MUST
a value of "Per-Peer Policy" in the Binding Revocation Indication contain a value of "Per-Peer Policy" in the Binding Revocation
to request the LMA to remove all Per-Peer bindings that are Indication to request the LMA to remove all Per-Peer bindings that
registered with the LMA and hosted at this MAG. In this case, the are registered with the LMA and hosted at this MAG. In this case,
MN-ID option MUST be included in the BRI and contains the mobile the MN-ID option MUST be included in the BRI and contain the
access gateway identity. In this case the mobile access gateway mobile access gateway identity. In addition, the mobile access
MAY include one or more Alternate Care-of Address option(s). The gateway MAY include one or more Alternate Care-of Address
Alternate Care-of Address option(s) include the proxy Care-of option(s). The Alternate Care-of Address option(s) contain the
address(es) which their bindings are being impacted by this BRI proxy Care-of address(es) which their bindings are being impacted
message. 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
skipping to change at page 30, line 9 skipping to change at page 29, line 37
10.2.2. Receiving Binding Revocation Acknowledgement 10.2.2. Receiving Binding Revocation Acknowledgement
When the mobile access gateway receives a packet carrying a valid When the mobile access gateway receives a packet carrying a valid
Binding Revocation Acknowledgement that was successfully processed Binding Revocation Acknowledgement that was successfully processed
according to Section 7.2, the mobile access gateway MUST process the according to Section 7.2, the mobile access gateway MUST process the
BRA as per the followings: BRA as per the followings:
o When the mobile access gateway receives a packet carrying a valid o When the mobile access gateway receives a packet carrying a valid
Binding Revocation Acknowledgement and the Global (G) and Proxy Binding Revocation Acknowledgement and the Global (G) and Proxy
MIPv6 (P) bits are set and the mobile nodes BCEs are in the state Binding (P) bits are set and the mobile nodes BCEs are in the
of Revocation in Progress, the mobile access gateway SHOULD state of Revocation in Progress, the mobile access gateway SHOULD
examine the Status field as follows: examine the Status field as follows:
o If the Status field indicates that the Binding Revocation o If the Status field indicates that the Binding Revocation
Indication was processed successfully, the mobile access gateway Indication was processed successfully, the mobile access gateway
delete the MINDelayBRIs timer and the mobile nodes proxy bindings delete the MINDelayBRIs timer and the mobile nodes proxy bindings
and all associated resources. and all associated resources.
o If the Status field indicates (Global Revocation NOT Authorized), o If the Status field indicates (Global Revocation NOT Authorized),
the mobile access gateway is not authorized to participate in a the mobile access gateway is not authorized to participate in a
Per-Peer Global Revocation. The mobile access gateway SHOULD NOT Per-Peer Global Revocation. The mobile access gateway SHOULD NOT
retry sending a Binding Revocation Indication with the Global (G) retry sending a Binding Revocation Indication with the Global (G)
bit is set to the same local mobility agent. The mobile access bit set to the same local mobility agent. The mobile access
gateway should raise an alarm or log an event to indicate this gateway should raise an alarm or log an event to indicate this
rejection. rejection.
11. Mobile Node Operation 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 and that its Binding Update routing header is its Home Address and that its Binding Update
List contains an entry for that Home Address. If one of the List contains an entry for that Home Address. If one of the
tests, fails the mobile node SHOULD silently discard the received tests, fails the mobile node SHOULD silently discard the received
BRI message. 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 its Binding Update List contains an entry for the Indication and its Binding Update List contains an entry for the
IP address in the type 2 routing header, the mobile node MUST send IP address in the Type 2 routing header, the mobile node MUST send
a Binding Revocation Acknowledgement. However, in all other cases a Binding Revocation Acknowledgement. However, in all other cases
when the (A) bit is set in the BRI, the mobile node SHOULD send a when the (A) bit is set in the BRI, the mobile node SHOULD send a
Binding Revocation Acknowledgement. In all cases, the mobile node Binding Revocation Acknowledgement. In all cases, the mobile node
MUST follow Section 11.2 and send a BRA using the appropriate MUST follow Section 11.2 and send a BRA using the appropriate
status code. status code.
o If the IPv4 HoA Binding Only (V) bit is set in the received BRI o If the IPv4 HoA Binding Only (V) bit is set in the received BRI
message, the MN MUST verify that there is an IPv4 Home Address message, the MN MUST verify that there is an IPv4 Home Address
option in the received BRI and the IPv4 address included in the 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 IPv4 Home Address option is the same as its IPv4 HoA that is
assigned to the mobile node. If this verification is successful, assigned to the mobile node. If this verification is successful,
the MN MUST consider this BRI as an indication to release the the MN MUST consider this BRI as an indication to release the
mobile node IPv4 HoA binding ONLY to its current Care-of Address. mobile node IPv4 HoA binding ONLY to its current Care-of Address.
Consequently, the MN MUST continue to maintain its IPv6 HoA Consequently, the MN MUST continue to maintain its IPv6 HoA
binding to the current CoA as part of the mobile node binding in binding to the current CoA as part of the mobile node binding in
the BUL entry and release all resources associated with the MN the BUL entry and release all resources associated with the MN
IPv4 HoA binding. In this case, the MN MUST send a BRA message IPv4 HoA binding. In this case, the MN MUST send a BRA message
with the status field is set to success. On the other hand, if with the status field is set to "success". On the other hand, if
the IPv4 Home Address Option was NOT included in the received BRI the IPv4 Home Address Option was NOT included in the received BRI
with the (V) bit set, the MN SHOULD send a BRA message with the with the (V) bit set, the MN SHOULD send a BRA message with the
status field set to "IPv4 Home Address Option Required". status field set to "IPv4 Home Address Option Required".
Additionally, if the IPv4 HoA received in the IPv4 Home Address Additionally, if the IPv4 HoA received in the IPv4 Home Address
Option is NOT the one assigned to the MN, the MN SHOULD send a BRA Option is NOT the one assigned to the MN, the MN SHOULD send a BRA
with the status field set to "IPv4 HoA Binding Does NOT Exist". with the status field set to "Binding Does NOT Exist".
o The mobile node MUST verify that the (P) bit in the Binding o The mobile node MUST verify that the (P) bit in the Binding
Revocation Indication is NOT set. If the (P) bit is set, the Revocation Indication is NOT set. If the (P) bit is set, the
mobile node MUST silently discard the Binding Revocation mobile node MUST silently discard the Binding Revocation
Indication message. Indication message.
o If the mobile node has registered multiple care-of addresses with o If the mobile node has registered multiple care-of addresses with
its home agent, the mobile node MUST verify which binding is being its home agent, the mobile node MUST verify which binding is being
revoked by examining the content of the BRI message. If the revoked by examining the content of the 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 Address bindings with its
home agent and received a Binding Revocation Indication, without home agent and received a Binding Revocation Indication, without
any Binding ID option included and its home address was included any Binding ID option included and its home address was included
in the type 2 routing header, the mobile node MUST consider all of in the Type 2 routing header, the mobile node MUST consider all of
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
skipping to change at page 32, line 46 skipping to change at page 32, line 20
The default value for this parameter is 1. The default value for this parameter is 1.
Minimum Delay Between BRI messages (MINDelayBRIs) Minimum Delay Between BRI messages (MINDelayBRIs)
This variable specifies the delay time in seconds before the This variable specifies the delay time in seconds before the
revoking mobility entity retransmits a BRI message. The default revoking mobility entity retransmits a BRI message. The default
is 1 second but not less than 0.5 seconds. is 1 second but not less than 0.5 seconds.
13. IANA Considerations 13. IANA Considerations
This document defines a new Binding Revocation Message using a new This specification defines a new Binding Revocation Message using a
Mobility Header Type <IANA-TBD>, as described in Section 6. The new new Mobility Header Type <IANA-TBD>, as described in Section 6. The
Mobility Header type value needs to be assigned from the same new Mobility Header type value needs to be assigned from the same
numbering space as allocated for the other Mobility Header types. numbering space as allocated for the other Mobility Header types.
This document also creates a new name space "Binding Revocation Type" This document also creates a new name space "Binding Revocation Type"
which indicates the type of the binding revocation message. The which indicates the type of the binding revocation message. The
current binding revocation message types are described in Section 6.1 current binding revocation message types are described in Section 6.1
and Section 6.2, and are the following: and Section 6.2, and are the following:
0 Reserved 0 Reserved
1 Binding Revocation Indication 1 Binding Revocation Indication
2 Binding Revocation Acknowledgement 2 Binding Revocation Acknowledgement
skipping to change at page 33, line 28 skipping to change at page 33, line 5
In addition, this document also creates a second new namespace for In addition, this document also creates a second new namespace for
the Binding Revocation Trigger which indicates the reason behind the Binding Revocation Trigger which indicates the reason behind
sending the Binding Revocation Indication message. The current sending the Binding Revocation Indication message. The current
Binding Revocation Trigger values are described in Section 6.1, and Binding Revocation Trigger values are described in Section 6.1, and
are the following: are the following:
Reserved and Per-MN Revocation Trigger Values: Reserved and Per-MN Revocation Trigger Values:
0 Reserved 0 Reserved
1 Unspecified 1 Unspecified
2 Administrative Reason 2 Administrative Reason
3 Inter-MAG Handoff - same Access Types 3 Inter-MAG Handover
4 Inter-MAG Handoff - different Access Types 4 User Initiated Session(s) Termination
5 Inter-MAG - Unknown Handoff 5 Access Network Session(s) Termination
6 User Initiated Session(s) Termination 6 Possible Out-of Sync BCE State
7 Access Network Session(s) Termination
8 IPv4 HoA Lease Expires
9 Possible Out-of Sync BCE State
250-255 Reserved For Testing Purposes only 250-255 Reserved For Testing Purposes only
All other values are Reserved All other values are Reserved
Global Revocation Trigger Values: Global Revocation Trigger Values:
128 Per-Peer Policy 128 Per-Peer Policy
129 Revoking Mobility Node Local Policy 129 Revoking Mobility Node Local Policy
Future values of the Binding Revocation Trigger can be allocated Future values of the Binding Revocation Trigger can be allocated
using Standards Action or IESG Approval [RFC2434]. using Standards Action or IESG Approval [RFC2434].
Furthermore, this document creates a third new name space "Status Furthermore, this document creates a third new name space "Status
Code" for the Status field in the Binding Revocation Acknowledgement Code" for the Status field in the Binding Revocation Acknowledgement
message. The current values are described in Section 6.2, and are message. The current values are described in Section 6.2, and are
the following: the following:
0 success 0 success
1 partial success 1 partial success
128 Binding Does NOT Exist 128 Binding Does NOT Exist
129 IPv4 HoA Binding Does NOT Exist 129 IPv4 Home Address Option Required
130 IPv4 Home Address Option Required 130 Global Revocation NOT Authorized
131 Global Revocation NOT Authorized 131 Revoked Mobile Nodes Identity Required
132 CAN NOT Identify Binding 132 Revocation Failed - MN is Attached
133 Revocation Failed - MN is Attached 133 Revocation Trigger NOT Supported
134 Revocation Function NOT Supported
Future values of the Status field can be allocated using Standards Future values of the Status field can be allocated using Standards
Action or IESG Approval [RFC2434]. Action or IESG Approval [RFC2434].
All fields labeled "Reserved" are only to be assigned through All fields labeled "Reserved" are only to be assigned through
Standards Action or IESG Approval. Standards Action or IESG Approval.
14. Security Considerations 14. Security Considerations
The protocol described here uses the same security association The protocol described here uses the same security association
skipping to change at page 34, line 48 skipping to change at page 34, line 21
Devarapalli, and Joel Hortelius for their review and comments of this Devarapalli, and Joel Hortelius for their review and comments of this
draft and all colleagues who have supported the advancement of this draft and all colleagues who have supported the advancement of this
draft effort. draft effort.
16. References 16. References
16.1. Normative References 16.1. Normative References
[ID-DSMIP6] [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-07 (work in Routers", draft-ietf-mext-nemo-v4traversal-09 (work in
progress), December 2008. progress), February 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-11 (work in progress), draft-ietf-monami6-multiplecoa-12 (work in progress),
January 2009. March 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-09 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-10
(work in progress), January 2009. (work in progress), March 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
 End of changes. 55 change blocks. 
145 lines changed or deleted 129 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/