draft-ietf-mext-binding-revocation-00.txt   draft-ietf-mext-binding-revocation-01.txt 
MEXT WG 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 1, 2009 S. Gundavelli Expires: March 1, 2009 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
P. Yegani P. Yegani
Cisco Systems Cisco Systems
July 31, 2008 August 28, 2008
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-00.txt draft-ietf-mext-binding-revocation-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 1, 2009. This Internet-Draft will expire on March 1, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines the revocation semantics for terminating a This document defines the revocation semantics for terminating a
mobile node's mobility session and associated resources. These mobile node's mobility session and associated resources. These
semantics are generic enough and can be used by mobility entities in semantics are generic enough and can be used by mobility entities in
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2.1. Conventions used in this document . . . . . . . . . . . . 4 2.1. Conventions used in this document . . . . . . . . . . . . 4
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4
3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5
3.2. Client MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . 6 3.2. Client MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . 6
3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7
3.3.1. Termination of Multiple Care-of Addresses Bindings . . 7 3.3.1. Termination of Multiple Care-of Addresses Bindings . . 7
3.3.2. Termination of All Care-of Addresses Bindings . . . . 8 3.3.2. Termination of All Care-of Addresses Bindings . . . . 8
3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8
3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding . . . . 8
3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 10 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings . . 9
3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings . . 10 3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings . . 10
4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Binding Revocation Messages . . . . . . . . . . . . . . . . . 10 5. Exchanging Binding Revocation Messages over an IPv4
5.1. Binding Revocation Indication Message . . . . . . . . . . 10 Transport Network . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Binding Revocation Acknowledgement Message . . . . . . . . 13 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 10
6. Binding Revocation Process Considerations . . . . . . . . . . 15 6.1. Binding Revocation Indication Message . . . . . . . . . . 12
6.1. Sending Binding Revocation Messages . . . . . . . . . . . 15 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 14
6.2. Receiving Binding Revocation Messages . . . . . . . . . . 15 7. Binding Revocation Process Considerations . . . . . . . . . . 16
6.3. Retransmission of Binding Revocation Indication . . . . . 16 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 16
7. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 16 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 17
7.1. Sending Binding Revocation Indication . . . . . . . . . . 16 7.3. Retransmission of Binding Revocation Indication . . . . . 18
7.2. Receiving Binding Revocation Acknowledgement . . . . . . . 18 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 18
8. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 18 8.1. Sending Binding Revocation Indication . . . . . . . . . . 18
8.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 18 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 20
8.1.1. Sending Binding Revocation Indication . . . . . . . . 18 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 20
8.1.2. Receiving Binding Revocation Acknowledgement . . . . . 20 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 20
8.2. Binding Revocation Responder . . . . . . . . . . . . . . . 21 9.1.1. Sending Binding Revocation Indication . . . . . . . . 20
8.2.1. Receiving Binding Revocation Indication . . . . . . . 21 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 23
8.2.2. Sending Binding Revocation Acknowledgement . . . . . . 22 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 23
9. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 23 9.2.1. Receiving Binding Revocation Indication . . . . . . . 23
9.1. Binding Revocation Responder . . . . . . . . . . . . . . . 23 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 24
9.1.1. Receiving Binding Revocation Indication . . . . . . . 23 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 25
9.1.2. Sending Binding Revocation Acknowledgement . . . . . . 24 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 25
9.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 25 10.1.1. Receiving Binding Revocation Indication . . . . . . . 25
9.2.1. Sending Binding Revocation Indication . . . . . . . . 25 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 27
9.2.2. Receiving Binding Revocation Acknowledgement . . . . . 26 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 27
10. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 26 10.2.1. Sending Binding Revocation Indication . . . . . . . . 27
10.1. Receiving Binding Revocation Indication . . . . . . . . . 26 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 28
10.2. Sending Binding Revocation Acknowledgement . . . . . . . . 27 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 29
11. Protocol Configuration Variables . . . . . . . . . . . . . . . 28 11.1. Receiving Binding Revocation Indication . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 30
13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Security Considerations . . . . . . . . . . . . . . . . . . . 31
15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
15.2. Informative References . . . . . . . . . . . . . . . . . . 30 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 34
1. Introduction 1. Introduction
In the case of Mobile IPv6 and for administrative reason, sometimes In the case of Mobile IPv6 and for administrative reason, sometimes
it becomes necessary to inform the mobile node that its registration it becomes necessary to inform the mobile node that its registration
has been revoked and the mobile node is no longer able to receive IP has been revoked and the mobile node is no longer able to receive IP
mobility service using its Home Address. In some networks where mobility service using its Home Address. In some networks where
Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4 Mobile IPv4 [RFC3344] has been deployed, a similar Mobile IPv4
registration revocation mechanism has been specified [RFC3543]. registration revocation mechanism has been specified [RFC3543].
This document defines the semantics of the revocation mechanism of a This document defines the semantics of the revocation mechanism of a
mobile node registration binding, which could have been established mobile node registration binding, which could have been established
using a Client Mobile IPv6 or any of its extensions, e.g. Proxy using a Client Mobile IPv6 or any of its extensions, e.g. Proxy
Mobile IPv6 signaling. The proposed revocation mechanism uses the Mobile IPv6 signaling. The proposed revocation mechanism uses a new
Mobile IPv6 Generic Signalling Message framework as defined in MH type <IANA-TBD> for revocation signaling which is applicable to
[ID-MGSM] which has a generic message framework which is applicable Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [RFC5213] and can be used
to Mobile IPv6 [RFC3775] and Proxy Mobile IPv6 [ID-PMIP6] and can be by any two IP mobility entities. As an example, this mechanism
used by any two IP mobility entities. As an example, this mechanism allows a local mobility anchor, involved in providing IP mobility
allows a local mobility agent, involved in providing IP mobility services to a mobile node, to notify the mobile access gateway of the
services to a mobile node, to notify the mobility access gateway of termination of a mobile node binding registration. In another
the termination of a mobile node binding registration. In another example, a mobile access gateway can use this mechanism to notify its
example, a mobility access gateway can use this mechanism to notify local mobility anchor peer with a bulk termination of all or a subset
its local mobility anchor peer with a bulk termination of all Proxy of Proxy Mobile IPv6 bindings that are registered with the local
MIPv6 bindings that are registered with the local mobility anchor and mobility anchor and currently being served by the mobile access
currently being served by the mobility access gateway. gateway.
2. Conventions & Terminology 2. Conventions & Terminology
2.1. Conventions used in this document 2.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Terminology 2.2. Terminology
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 specification [RFC3775] and be interpreted as defined in Mobile IPv6 specification [RFC3775] and
Proxy Mobile IPv6 specification [ID-PMIP6]. Proxy Mobile IPv6 specification [RFC5213].
3. Binding Revocation Protocol and Use Cases Overview 3. Binding Revocation Protocol and Use Cases Overview
This specification defines a binding revocation mechanism using the This specification defines a binding revocation mechanism where a
framework of Mobile IPv6 Generic Signaling Message (MGSM), where a
mobility node can communicate to the mobile node or another mobility mobility node can communicate to the mobile node or another mobility
node the termination of the mobile node registration binding. The node the termination of the mobile node registration binding. The
following subsections describe the protocol overview and applicable following subsections describe the protocol overview and applicable
use cases. use cases.
3.1. Binding Revocation Protocol 3.1. Binding Revocation Protocol
In the case of Client Mobile IPv6, the revocation procedure can be In the case of Client Mobile IPv6, the revocation procedure can be
initiated by the home agent. If the home network decides to initiated by the home agent. If the home network decides to
terminate the service of the mobile node, the home agent sends a terminate the service of the mobile node, the home agent sends a
Binding Revocation Indication (BRI) message to the mobile node. The Binding Revocation Indication (BRI) message to the mobile node. The
home agent includes the HoA option as specified in [RFC3775] to home agent includes the HoA option as specified in [RFC3775] to
indicate the impacted mobile node session. When the mobile node indicate the impacted mobile node binding. When the mobile node
receives a BRI message with its HoA included and the Acknowledge (A) receives a BRI message with its HoA included and the Acknowledge (A)
bit is set, the mobile node responds by sending a Binding Revocation bit is set, the mobile node responds by sending a Binding Revocation
Acknowledgement (BRA) message. Acknowledgement (BRA) message.
In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also In the case of DSMIPv6 [ID-DSMIP6], the revocation procedure can also
be initiated by the home agent. If the home network decides to be initiated by the home agent. If the home network decides to
terminate the service of the mobile node, the home agent sends a BRI terminate the service of the mobile node, the home agent sends a BRI
message to the mobile node to indicate the termination the mobile message to the mobile node to indicate the termination of the mobile
node IP Mobility service. The home agent may include the HoA option node IP Mobility service. The home agent may include the HoA option
with the mobile node assigned home IPv4 address. After receiving the with the mobile node assigned home IPv4 address. After receiving the
BRI message with the Acknowledge (A) bit is set, the mobile node BRI message with the Acknowledge (A) bit is set, the mobile node
responds by sending a BRA message. responds by sending a BRA message.
Similarly, in the case of Proxy Mobile IPv6 [ID-PMIP6], the Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation
revocation procedure can be initiated by the local mobility anchor by procedure can be initiated by the local mobility anchor by sending a
sending a BRI message to communicate the termination of a mobile node BRI message to communicate the termination of a mobile node
registration binding to the mobility access gateway. In this case, registration binding to the mobility access gateway. In this case,
the local mobility anchor includes the mobile node Home Network the local mobility anchor includes the mobile node Home Network
Prefix option [ID-PMIP6] and the MN-ID option [RFC4283] to indicate Prefix option [RFC5213] and the MN-ID option [RFC4283] to indicate to
to the mobility access gateway the identity of the PMIPv6 binding the mobility access gateway the identity of the PMIPv6 binding that
that needs to be terminated. When the mobility access gateway needs to be terminated. When the mobility access gateway receives
receives the BRI message with the (A) bit set, the mobility access the BRI message with the (A) bit set, the mobility access gateway
gateway responds to the local mobility anchor by sending a BRA responds to the local mobility anchor by sending a BRA message.
message.
On the other hand, the mobility access gateway usually sends a de- On the other hand, the MAG usually sends a de-registration message by
registration message by sending a Proxy BU with a lifetime of zero to sending a Proxy BU with a lifetime of zero to indicate to the LMA of
indicate to the local mobility anchor of the termination of the the termination of the PMIPv6 mobile node binding registration. In
PMIPv6 mobile node binding registration. In this case, the mobility this case, the MAG includes the MN HNP option, the MN-ID option and
access gateway include the MN home network prefix option and the all other required mobility options as per [RFC5213] in order for the
MN-ID option as per [ID-PMIP6] in order for the local mobility anchor LMA to identify the mobile node PMIPv6 binding. However, in the case
to identify the mobile node PMIPv6 binding. However, in the case
when the mobility access gateway communicates a bulk termination of when the mobility access gateway communicates a bulk termination of
PMIPv6 sessions, the mobility access gateway sends a BRI message with PMIPv6 sessions, the MAG sends a BRI message with the (G) and (A)
the G bit set and includes the mobility access gateway identity in bits are set and includes the MAG identity in the MN-ID option. When
the MN-ID option. When the local mobility anchor receives such BRI the LMA receives such BRI message, it ensures that the mobility
message, it ensures that the mobility access gateway is authorized to access gateway is authorized to send such bulk termination message
send such bulk termination message and then process the BRI message and then process the BRI message accordingly. If the local mobility
accordingly. If the local mobility anchor processes the BRI message anchor processes the BRI message successfully and since the (A) bit
successfully and the (A) bit is set in the BRI, the local mobility is set, the LMA responds to the mobile access gateway by sending the
anchor responds to the mobile access gateway by sending a BRA BRA message. Additionally, the initiator of the binding revocation
message. Additionally, the initiator of the binding revocation procedure includes an indication in the Revocation Trigger field to
procedure include an indication in the Revocation Trigger field to
indicate to the receiving node the cause for the revocation indicate to the receiving node the cause for the revocation
procedure. procedure.
3.2. Client MIPv6 and DSMIP6 Use Case 3.2. Client MIPv6 and DSMIP6 Use Case
Binding revocation mechanism is applicable to Client Mobile IPv6 and Binding revocation mechanism is applicable to Client Mobile IPv6 and
DSMIPv6 session when the home agent needs to inform the mobile node DSMIPv6 session(s) when the home agent needs to inform the mobile
that its binding registration has been revoked, e.g. for an node that its binding registration has been revoked, e.g. for an
administrative reason. This mechanism enables the home domain to administrative reason. This mechanism enables the home domain to
dynamically allow the user to act upon the revocation message in dynamically allow the user to act upon the revocation message in
order to not have an unexpectedly interrupted mobile IPv6 services. order to not have an unexpectedly interrupted mobile IPv6 services.
In this case, the home agent sends a BRI message to indicate to the In this case, the home agent sends a BRI message to indicate to the
mobile node that its current mobile IPv6 binding has been revoked and mobile node that its current mobile IPv6 binding has been revoked and
it no longer can receive IP mobility service. The home agent it no longer can receive IP mobility service. The home agent
includes the mobile node home address in HoA option, in the includes the mobile node home address in HoA option in the
destination option header as used in [RFC3775] and sets the destination option header as used in [RFC3775] and sets the
Revocation Trigger field to a proper value, e.g. Administrative. In Revocation Trigger field to a proper value, e.g. Administrative
the case of DSMIPv6 session, the home agent may additionally include Reason. In the case of DSMIPv6 session, the home agent may
the mobile node assigned IPv4 Home Address Option . When the mobile additionally include the mobile node assigned IPv4 Home Address
node receives the BRI message, it sends a BRA message as described in Option. When the mobile node receives the BRI message, it sends a
Section 10.2 to the home agent. Figure 1 illustrates the message BRA message as described in Section 11.2 to the home agent. Figure 1
sequencing when home agent revokes a mobile node binding illustrates the message sequencing when home agent revokes a mobile
registration. node binding registration.
MN HA MN HA
| | | |
| HoA in Dest. Opt. Hdr + BRI[seq.#, A bit] | | HoA in Dest. Opt. Hdr + BRI[seq.#, A bit] |
|<------------------------------------------| |<------------------------------------------|
| | | |
| | | |
| | | |
| BRA[seq.#] | | BRA[seq.#] |
|------------------------------------------>| |------------------------------------------>|
| | | |
| | | |
Figure 1: Home Agent Revokes a Mobile Node Binding Registration Figure 1: Home Agent Revokes a Mobile Node Binding Registration
3.3. Multi-Care of Addresses (Monami6) Use Case 3.3. Multi-Care of Addresses (Monami6) Use Case
In the case of Monami6 protocol, a mobile node is able to register In the case of Monami6 protocol, a mobile node is able to register
multiple care-of addresses for the same home address [ID-MCoA]. multiple care-of addresses for the same home address [ID-MCoA].
Binding revocation mechanism is applicable to Monami6 when the home Binding revocation mechanism is applicable to Monami6 when the HA
agent sends a BRI message to revoke a single or more care-of address sends a BRI message to revoke a single or more care-of address
bindings. bindings.
3.3.1. Termination of Multiple Care-of Addresses Bindings 3.3.1. Termination of Multiple Care-of Addresses Bindings
In the case of multiple care-of addresses, the home agent maintains In the case of multiple care-of addresses, the home agent maintains
different binding for each pair of care-of address and home address. different binding for each pair of care-of address and home address.
These bindings are also indexed and identified during the mobile node These bindings are also indexed and identified during the mobile node
registration using a new Binding ID mobility option [ID-MCoA]. In registration using a Binding ID mobility option [ID-MCoA]. In this
this case, the home agent may revoke any binding, more than one case, the HA may revoke any binding, more than one binding, or all of
binding, or all of the bindings for the same mobile node home the bindings for the same mobile node home address.
address.
In the case when home agent revokes a single binding for a mobile In the case when home agent revokes a single binding for a mobile
node with multiple care-of addresses registration, the home agent node with multiple care-of addresses registration, the home agent
send a BRI message to the mobile node with the corresponding BID sends a BRI message to the mobile node with the corresponding BID
option included and the HoA option in the destination option header. option included and the HoA option in the destination option header.
If the home agent needs to revoke more than one of the mobile node If the home agent needs to revoke more than one of the mobile node
registered care-of addresses, the home agent includes all the registered care-of addresses, the home agent includes all the
corresponding BID options which reference these care-of addresses in corresponding BID options which reference these care-of addresses in
the same BRI message. Figure 2 illustrates the message flow when the the same BRI message. Figure 2 illustrates the message flow when the
home agent revokes two registered Care-of addresses for the same MN HA revokes two registered Care-of addresses for the same MN in a
in a single BRI message. The home agent can revoke any registered single BRI message. The home agent can revoke any registered
bindings by sending a BRI message to the respective mobile node. binding(s) by sending a BRI message to the respective mobile node.
HA Binding Cache HA Binding Cache
================ ================
MN-BID1 [CoA1+HoA] MN-BID1 [CoA1+HoA]
MN HA MN-BID2 [CoA2+HoA] MN HA MN-BID2 [CoA2+HoA]
| | MN-BID3 [CoA3+HoA] | | MN-BID3 [CoA3+HoA]
| BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA] | BRI [seq.#, A bit, BID1, BID4 options] | MN-BID4 [CoA4+HoA]
|<------------------------------------------| |<------------------------------------------|
| | | |
| | | |
skipping to change at page 8, line 21 skipping to change at page 8, line 20
illustrates the message flow when the home agent revokes all 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
message. message.
3.4. Proxy MIPv6 Use Case 3.4. Proxy MIPv6 Use Case
Since the Mobile node does not participate in the mobility mechanism Since the Mobile node does not participate in the mobility mechanism
in the case of PMIPv6, there are many scenarios where Binding in the case of PMIPv6, there are many scenarios where Binding
Revocation mechanism is needed to clean resources and make sure that Revocation mechanism is needed to clean resources and make sure that
the mobility entities, e.g. MAG and LMA, are always synchronized the mobility entities, e.g. MAG and LMA, are always synchronized
with the status of the existing proxy mobile IPv6 bindings. The with respect to the status of the existing proxy mobile IPv6
binding revocation mechanism is generic enough that can be used in bindings. The binding revocation mechanism is generic enough that
all applicable PMIPv6 scenarios and deployment options. For example, can be used in all applicable PMIPv6 scenarios and deployment
this revocation mechanism is still applicable and can be used when options. For example, this revocation mechanism is still applicable
PMIPv6 is deployed with IPv6 or IPv4 transports and when the mobile and can be used when PMIPv6 is deployed with IPv6 or IPv4 transports
node uses IPv4 or IPv6 address as specified in [ID-PMIP6-IPv4]. and when the mobile node uses IPv4 or IPv6 address as specified in
[ID-PMIP6-IPv4].
When the mobile access gateway receives a BRI message as in When the MAG receives a BRI message as in Section 10.1.1, the MAG
Section 9.1.1, the mobile access gateway sends a BRA message to the sends a BRA message to the LMA following the rules describes in
local mobility anchor following the rules describes in Section 9.1.2. Section 10.1.2. Similarly if the LMA receives a BRI message with the
Similarly if the local mobility anchor receives a BRI message with (A) bit is set, the LMA responds to the MAG by sending a BRA message.
the A bit is set, the local mobility anchor responds to the mobile
access gateway by sending a BRA message.
3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding 3.4.1. Local Mobility Anchor Revokes A PMIPv6 Binding
The local mobility anchor may send a BRI message to the mobile access The local mobility anchor may send a BRI message to the mobile access
gateway, hosting a specific proxy mobile IPv6 session, with the gateway, hosting a specific proxy mobile IPv6 binding, with the
appropriate value in the revocation trigger field to indicate that appropriate value in the revocation trigger field to indicate that
the mobile node binding has been terminated and the mobile access the mobile node binding has been terminated and the MAG can clean up
gateway can clean up the applicable resources. When the mobile the applicable resources. When the MAG receives a BRI message, the
access gateway receives a BRI message, the MAG identify the respected MAG identify the respected binding and if the (A) bit was set in the
binding and if the A bit was set in the received BRI message, the MAG received BRI message, the MAG sends a BRA message to the LMA. In
sends a BRA message to the LMA. In this case, the MAG could send a this case, the MAG could send a Router Advertisement message to the
Router Advertisement message to the MN with the home network prefix MN with the home network prefix lifetime is set to zero.
lifetime is set to zero.
As an example, Figure 3, illustrates the message sequence for As an example, Figure 3, illustrates the message sequence for
revoking a mobile node binding at the source MAG during the MN inter- revoking a mobile node binding at the source MAG during the MN inter-
MAG handoff. During the inter-MAG handoff, the mobile node moves MAG handoff. During the inter-MAG handoff, the mobile node moves
from the source MAG to the target MAG. The target MAG sends a PBU from the source MAG to the target MAG. The target MAG sends a PBU
with the new care-of-address to the LMA to update the mobile node with the new care-of-address to the LMA to update the mobile node
point of attachment. Since the MN binding at the LMA points to the point of attachment. Since the MN binding at the LMA points to the
source MAG and upon receiving the PBU from the target MAG, LMA source MAG and upon receiving the PBU from the target MAG, LMA
updates the MN BCE and send a PBA to the target MAG. LMA can send a updates the MN BCE and send a PBA to the target MAG. LMA can send a
BRI message with the appropriate revocation trigger value, e.g. BRI message with the appropriate revocation trigger value, e.g.
inter-MAG handoff indication, to the source MAG in order to clean up inter-MAG handoff - same Access Types, to the source MAG in order to
the applicable resources reserved for the specified MN. The MAG clean up the applicable resources reserved for the specified MN
acknowledges the BRI message by sending a BRA message to indicate the binding. The MAG acknowledges the BRI message by sending a BRA
success or failure of the termination of the mobile node binding. message to indicate the success or failure of the termination of the
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 handoff 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.
sMAG tMAG LMA sMAG tMAG LMA
| | | | | |
| | PBU | | | PBU |
| |--------------------------->| | |--------------------------->|
skipping to change at page 10, line 7 skipping to change at page 9, line 45
| | | | | |
| BRA [seq.#, Cause, P bit] | | BRA [seq.#, Cause, P bit] |
|----------------------------------------->| |----------------------------------------->|
| | | | | |
| | | | | |
Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff Figure 3: LMA Revokes a MN Registration During Inter-MAG Handoff
3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings 3.4.2. Local Mobility Anchor Revokes Bulk PMIPv6 Bindings
The local mobility anchor sends a BRI message to indicate that all The LMA sends a BRI message to indicate that all bindings which are
bindings which are hosted by the peer mobile access gateway and hosted by the peer MAG and registered with the LMA are being revoked
registered with the local mobility anchor are being revoked by by setting the (G) bit as described in Section 9.1.1.
setting the G bit as described in Section 8.1.1.
3.4.3. Mobile Access Gateway Revoke Bulk PMIPv6 Bindings 3.4.3. Mobile Access Gateway Revoke 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 sessions which are registered at the to indicate that all mobility bindings which are registered at the
LMA and attached to the MAG are being revoked as in Section 9.2.1. LMA and attached to the MAG are being revoked as in Section 10.2.1.
When the LMA receives a BRI message with the G bit is set from a When the LMA receives a BRI message with the (G) bit is set from a
specified MAG, the LMA checks if the MAG is authorized to use global specified MAG, the LMA checks if the MAG is authorized to use global
revocations and responds with the appropriate status code by sending revocations and responds with the appropriate status code by sending
a BRA message as in Section 8.2.2. a BRA message as in Section 9.2.2.
4. Security Model 4. Security Model
The revocation protocol described here requires the revocation The binding revocation protocol described here uses the same security
messages to be defined as subtypes of the Mobile IPv6 Generic association between the MN and the HA or the MAG and the LMA that has
Signalling Message which is assigned a MH type value <IANA-TBD> been used to exchange the corresponding Client MIPv6 or Proxy MIPv6
[ID-MGSM] that requires IPsec protection. This is needed in order BU and BA when the mobile node binding was created. If IPsec is
when IPsec is used for securing the mobility signalling between , used, the SPD of the respected IPsec SA MUST allow the Binding
e.g., the MAG and the LMA, the IPsec SPD will allow all MGSM packets Revocation Signaling MH type <IANA-TBD> in order to allow BRI and BRA
including those which carry binding revocation messages. messages to be exchanged.
Additionally, in the case when the LMA receives a BRI which indicates Additionally, in the case when the LMA receives a BRI which indicates
a bulk termination, the LMA MUST verify that the MAG sending the a bulk termination, i.e., the (G) bit is set, the LMA MUST verify
revocation indication message is authorized for Per-Peer Global that the MAG sending the binding revocation indication message is
revocation. authorized to invoke Global revocation.
5. Binding Revocation Messages 5. Exchanging Binding Revocation Messages over an IPv4 Transport
Network
This section defines two messages by reserving two subtypes of the In some deployments, the network between the MAG and the LMA may only
Mobile IPv6 Generic Signalling Message that use the MH type which supports IPv4 transport. In this case, the Binding Revocation
requires IPsec protection as defined in [ID-MGSM]. messages (BRI and BRA) are tunneled over IPv4. If the Proxy Binding
Update and Proxy Binding Acknowledgment messages are sent using UDP
encapsulation to traverse NATs, then the Binding Revocation messages
are sent using the same UDP encapsulation. The same UDP port that
was used for the Proxy Binding Update and Proxy Binding
Acknowledgement messages will also be used when transporting Binding
Revocation messages over IPv4 using UDP encapsulation. For more
details on tunneling Proxy Mobile IPv6 signaling messages over IPv4,
see [ID-PMIP6-IPv4].
5.1. Binding Revocation Indication Message 6. Binding Revocation Message
The Binding Revocation Indication (BRI) message is used by the This section defines a Binding Revocation Message that use a MH type
revoking mobility node to inform the receiving mobility entity that <IANA-TBD> with a Binding Revocation type field that follow the MH
the IP mobility service of a specific binding or bindings have been format described in section 6.1. [RFC3775]. The value in the
revoked. Binding Revocation Indication message is sent as described Binding Revocation Type field as shown in Figure 4 defines the type
in Section 7.1, Section 8.1.1, and Section 9.2.1. of the Binding Revocation message, (BRI or BRA). If the Binding
Revocation type field is set to 1, the Binding Revocation Message is
a Binding Revocation Indication message as in Section 6.1. However,
when the Binding Revocation type field is set to a value 2, the
Binding Revocation Message is a Binding Revocation Acknowledgement
message as in Section 6.2.
The Binding Revocation Indication (BRI) message uses the subtype 0 1 2 3
<IANA-SUB1> of the MGSM message that use the MH type which requires 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
IPsec protection as in [ID-MGSM]. When this subtype is indicated in +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the subtype field of the MGSM, the format of the Message Data field | Payload Proto | Header Len | MH Type | Reserved |
in the MGSM message following the subtype field is as in Figure 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | B.R. Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. Binding Revocation Message Data .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Revocation Message
Binding Revocation Type
8-bit unsigned integer. It defines the type of Binding Revocation
Message. It can be assigned one of the following values:
0 Reserved.
1 Binding Revocation Indication Message.
2 Binding Revocation Acknowledgement Message.
All other values are reserved.
Binding Revocation Message Data
The Binding Revocation Message Data follows the Binding Revocation
Message format that is defined in this document for the specified
value in the Binding Revocation Type field. It is either a BRI as
in Section 6.1 or BRA as in Section 6.2.
6.1. Binding Revocation Indication Message
The Binding Revocation Indication (BRI) message is 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
to inform the receiving mobility entity that the IP mobility service
of a specific binding or bindings have been revoked. Binding
Revocation Indication message is sent as described in 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
Revocation Message, the format of the Binding Revocation Message Data
follows the Binding Revocation Indication message as in Figure 5
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 1 | R. Trigger |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | R. Trigger |P|A|G|Reserved | | Sequence # |P|A|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Revocation Indication Message Figure 5: Binding Revocation Indication Message
Sequence #
A 16-bit unsigned integer used by the sending mobility node to
match a returned Binding Revocation Acknowledgement with this
Binding Revocation Indication.
Revocation Trigger Revocation Trigger
8-bit unsigned integer indicting the event which triggered the 8-bit unsigned integer indicting the event which triggered the
revoking node to send the BRI message. The following Revocation revoking node to send the BRI message. The following Revocation
Trigger values are currently defined: Trigger values are currently defined:
0 Reserved. 0 Reserved.
1 Unspecified. 1 Unspecified.
2 Administrative Reason. 2 Administrative Reason.
3 Inter-MAG Handover over same Access Types. 3 Inter-MAG Handoff - same Access Types.
4 Inter-MAG Handover over different Access Types.
5 Per-Peer Policy. 4 Inter-MAG Handoff - different Access Types.
6 Local Policy. 5 Inter-MAG - Unknown Handoff.
6 Per-Peer Policy.
7 Revoking Node Local Policy.
8 User Initiated Session(s) Termination.
9 Access Network Session(s) Termination.
10 Possible Out-of Sync BCE State.
250-255 Reserved For Testing Purposes only.
All other values are Reserved.
Sequence #
A 16-bit unsigned integer used by the sending mobility node to
match a returned Binding Revocation Acknowledgement with this
Binding Revocation Indication.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set by the sending mobility node to The Proxy Binding (P) bit is set by the sending mobility node to
indicate that the revoked binding is a proxy MIPv6 binding. indicate that the revoked binding is a proxy MIPv6 binding.
Acknowledge (A) Acknowledge (A)
The Acknowledge (A) bit is set by the sending mobility node, e.g. The Acknowledge (A) bit is set by the sending mobility node, e.g.
LMA, HA, or MAG, to request a Binding Revocation Acknowledgement LMA, HA, or MAG, to request a Binding Revocation Acknowledgement
be returned upon receipt of the Binding Revocation Indication as be returned upon receipt of the Binding Revocation Indication as
in Section 7.1, Section 8.1.1, and Section 9.2.1. in Section 8.1, Section 9.1.1, and Section 10.2.1.
Global (G) Global (G)
The Global (G) bit is set by the sending mobility node, LMA or The Global (G) bit is set by the sending mobility node, LMA or
MAG, to request the termination of all Per-Peer mobility Bindings MAG, to request the termination of all Per-Peer mobility Bindings
that are served by the sending and receiving mobility entities as or Multiple Bindings which share a common identifier that are
in Section 8.1.1 and Section 9.2.1. served by the sending and receiving mobility entities as in
Section 9.1.1 and Section 10.2.1.
Reserved Reserved
These fields are unused. They MUST be initialized to zero by the These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. This document contains zero or more TLV-encoded mobility options. This document
does not define any new mobility option. The receiver MUST ignore does not define any new mobility option. The receiver MUST ignore
and skip any options which it does not understand. These mobility and skip any options which it does not understand. These mobility
option(s) are used by the receiving mobility entity to identify option(s) are used by the receiving mobility entity to identify
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 [ID-PMIP6]. This option is mandatory o Home Network Prefix option [RFC5213]. This option is mandatory
when the P bit is set. when the (P) bit is set.
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 the when the (P) bit is set. Additionally, If the (G) bit is set by
mobile access gateway, this option include the MAG identity. the mobile access gateway, this option carries the MAG identity.
o Binding ID mobility option [ID-MCoA]. This option is mandatory if o Binding ID mobility option [ID-MCoA]. This option is mandatory if
the sending mobility entity request to terminate one binding of a the sending mobility entity request to terminate one binding of a
multi care-of addresses bindings for the same mobile node. The multi care-of addresses bindings for the same mobile node. The
sending Mobility entity may include more than one of these sending mobility entity may include more than one of the BID
mobility options. mobility options.
o IPv4 Home Address option which contains the mobile node home IPv4 o IPv4 Home Address option which contains the mobile node home IPv4
address [ID-DSMIP6]. address [ID-DSMIP6].
If no options are present in this message, 4 octets of padding are If no options are present in this message, 4 octets of padding are
necessary and the Header Len field of the MGSM will be set to 1. necessary and the Header Len field of the Binding Revocation Message
will be set to 1.
5.2. Binding Revocation Acknowledgement Message
The Binding Revocation Acknowledgement is used to acknowledge receipt 6.2. Binding Revocation Acknowledgement Message
of a Binding Revocation Indication described in Section 5.1. This
packet is sent as described in Section 8.2.2, Section 9.1.2, and
Section 10.2.
The Binding Revocation Acknowledgement uses the subtype <IANA-SUB2> The Binding Revocation Acknowledgement (BRA) message is a Binding
of the MGSM message that use the MH type which requires IPsec Revocation Message which has a MH type <IANA-TBD> and a Binding
protection as in [ID-MGSM]. When this subtype is indicated in the Revocation Type value of 2. It is used to acknowledge the receipt of
subtype field of the MGSM, the format of the Message Data field in a Binding Revocation Indication message described in Section 6.1.
the MGSM message following the subtype field is as in Figure 5: This packet is sent as described in Section 9.2.2, Section 10.1.2,
and Section 11.2.
When the value 2 is indicated in the Binding Revocation type field of
the Binding Revocation Message, the format of the Binding Revocation
Message Data follows the Binding Revocation Acknowledgement message
as in Figure 6
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| B.R. Type = 2 | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Status |P|G| Reserved | | Sequence # |P|G| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. . . .
. Mobility options . . Mobility options .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Binding Revocation Acknowledgement Message Figure 6: Binding Revocation Acknowledgement Message
Sequence #
The sequence number in the Binding Revocation Acknowledgement is
copied from the Sequence Number field in the Binding Revocation
Indication. It is used by the revoking mobility entity, e.g. HA,
LMA, in matching this Binding Revocation Acknowledgement with the
outstanding BRI.
Status Status
8-bit unsigned integer indicating the result of processing the 8-bit unsigned integer indicating the result of processing the
Binding Revocation Indication message by the receiving mobility Binding Revocation Indication message by the receiving mobility
entity. The following status values are currently defined. entity. The following status values are currently defined.
0 success. 0 success.
1 partial success. 1 partial success.
2 Binding Does NOT Exist. 2 Binding Does NOT Exist.
3 Global Revocation NOT Authorized. 3 IPv4 HoA Binding Does NOT Exist.
4 CAN NOT Identify Binding. 4 Global Revocation NOT Authorized.
5 CAN NOT Identify Binding.
6 Revocation Failed, MN is Attached.
Sequence #
The sequence number in the Binding Revocation Acknowledgement is
copied from the Sequence Number field in the Binding Revocation
Indication. It is used by the revoking mobility entity, e.g. HA,
LMA, in matching this Binding Revocation Acknowledgement with the
outstanding BRI.
Proxy Binding (P) Proxy Binding (P)
The Proxy Binding (P) bit is set if the (P) bit is set in the The Proxy Binding (P) bit is set if the (P) bit is set in the
corresponding Binding Revocation Indication message. corresponding Binding Revocation Indication message.
Global (G) Global (G)
The Global (G) bit is set if the (G) bit is set in the The Global (G) bit is set if the (G) bit is set in the
corresponding BRI message. Section 8.2.2 and Section 9.1.2. corresponding BRI message. Section 9.2.2 and Section 10.1.2.
Reserved Reserved
These fields are unused. They MUST be initialized to zero by the These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Mobility Options Mobility Options
Variable-length field of such length that the complete Mobility Variable-length field of such length that the complete Mobility
Header is an integer multiple of 8 octets long. This field Header is an integer multiple of 8 octets long. This field
contains zero or more TLV-encoded mobility options. In the case contains zero or more TLV-encoded mobility options. In the case
when the Status field is set to success, no mobility option is when the Status field is set to success, no mobility option is
required. The mobility option(s) is usually used to communicate required. The mobility option(s) is usually used to communicate
information of the bindings that failed the revocation procedure. information of the bindings that failed the revocation procedure.
The following options are valid in a Binding Revocation The following options are valid in a Binding Revocation
Acknowledgement: Acknowledgement:
o Home Network Prefix option [ID-PMIP6]. This option is mandatory o Home Network Prefix option [RFC5213]. This option is mandatory
when the P bit is set. when the P bit is set.
o Mobile Node Identifier Option [RFC4283]. This option SHOULD be o Mobile Node Identifier Option [RFC4283]. This option SHOULD be
included if the Home Network Prefix option is included. included if the Home Network Prefix option is included.
o Binding ID mobility option [ID-MCoA]. This option MAY be included o Binding ID mobility option [ID-MCoA]. This option MAY be included
to indicate the specific Binding ID that the receiving node failed to indicate the specific Binding ID that the receiving node failed
to revoke. to revoke.
If no options are present in this message, 4 octets of padding are If no options are present in this message, 4 octets of padding are
necessary and the Header Len field of the MGSM will be set to 1. necessary and the Header Len field of the Binding Revocation Message
will be set to 1.
6. Binding Revocation Process Considerations 7. Binding Revocation Process Considerations
The following subsections describe the details of the binding The following subsections describe the details of the binding
revocation generic process by the different mobility entities. revocation generic process by the different mobility entities.
6.1. Sending Binding Revocation Messages 7.1. Sending Binding Revocation Messages
When sending a Binding Revocation message, the sending mobility node, When sending a Binding Revocation message, the sending mobility node,
initiator, follows the rules of constructing a MGSM as in [ID-MGSM] initiator, follows the rules of constructing a Mobility Header as in
and by setting the subtype field to a value <IANA-SUB1> to indicate a Section 9.2 of [RFC3775] with the exception of setting the MH Type
BRI message. field to <IANA-TBD and the appropriate value of the Binding
Revocation Type field.
The mobility entity which initiates the revocation process, The mobility entity which initiates the revocation process,
initiator, MUST use the underlying IPsec security association as initiator, MUST use the underlying IPsec security association that
described in [ID-MGSM] to secure the BRI and BRA messages has been used during the mobile node binding registration to secure
transmission with the responding mobility entity, responder. the BRI and BRA messages transmission with the responding mobility
entity, responder.
When a mobility entity initiate the binding revocation process by When a mobility entity initiate the binding revocation process by
sending a Binding Revocation Indication, the initiator MUST construct sending a Binding Revocation Indication message, the initiator MUST
the BRI message as described in Section 5.1. In the BRI message, the construct the BRI message as described in Section 6.1. In the BRI
initiator MUST set the Sequence Number field to the next sequence message, the initiator MUST set the Sequence Number field to the next
number available for Binding Revocation. Since sending Binding sequence number available for Binding Revocation. Since sending BRI
Revocation Indication messages is not done on a regular basis, a 16 messages is not done on a regular basis, a 16 bit sequence number
bit sequence number field is large enough to allow the initiator to field is large enough to allow the initiator to match the BRA to the
match the Binding Revocation Acknowledgement to the outstanding outstanding BRI with (A) bit set using the sequence number field
Binding Revocation Indication with (A) bit set using the sequence only.
number field only.
On the other hand, when the responder acknowledge the BRI message by On the other hand, when the responder acknowledge the BRI message by
sending a BRA, the responder follows the rules of constructing a MGSM sending a BRA, the responder MUST construct the Binding Revocation
as in [ID-MGSM] and by setting the subtype field to a value <IANA- Acknowledgement as described in Section 6.2. In this case, the
SUB12> to indicate a BRA message and MUST construct the Binding responder MUST set the Sequence Number field by copying the value
Revocation Acknowledgement as described in Section 5.2. In this from the Sequence Number field of the received Binding Revocation
case, the responder MUST set the Sequence Number field by copying the Indication. Additionally, it MUST set the status field to a valid
value from the Sequence Number field of the received Binding value that reflects the processing of the received Binding Revocation
Revocation Indication. Additionally, it MUST set the status field to Indication.
a valid value that reflects the processing of the received Binding
Revocation Indication.
6.2. Receiving Binding Revocation Messages 7.2. Receiving Binding Revocation Messages
When receiving a Binding Revocation message, the receiving mobility When receiving a Binding Revocation message, the receiving mobility
node MUST verify the Mobile IPv6 Generic Signaling Message as in node MUST verify the Mobility Header as in [RFC3775]. If the packet
[ID-MGSM]. If the packet is dropped due to the receiving node does is dropped due to failing any of the Mobility Headers test check, the
not support Binding Revocation Indication as a MGSM with subtype receiving node MUST follow the processing rules as in Section 9.2 of
<IANA-SUB1>, it MUST follow the processing rules as in [ID-MGSM] and [RFC3775]. For example, it MUST send a Binding Error message with
it MUST send a Binding Error message with the Status field set to 2 the Status field set to 2 (unrecognized MH Type value) if it does not
(unrecognized MH Type value). support the received binding revocation message type.
Since some mobility entities, e.g. LMA and MAG, are allowed to Since some mobility entities, e.g. LMA and MAG, are allowed to
receive and possibly send a BRI or a BRA for different cases, IPsec receive and possibly send a BRI or a BRA for different cases, IPsec
mechanism will prevent any possible man in the middle reflection mechanism will prevent any possible man in the middle reflection
attack. attack.
Upon receiving a packet carrying a Binding Revocation Indication, the Upon receiving a packet carrying a Binding Revocation Indication, the
receiving mobility entity, responder, validates that the packet was receiving mobility entity, responder, validates that the packet was
received protected with the underlying IPsec protection with the received protected with the underlying IPsec protection with the
responding mobility entity as described in [ID-MGSM]. responding mobility entity.
Upon receiving a packet carrying a Binding Revocation Upon receiving a packet carrying a Binding Revocation
Acknowledgement, the receiving mobility entity, initiator, MUST Acknowledgement, the receiving mobility entity, initiator, MUST
validate that Sequence Number field matches the Sequence Number of an validate that Sequence Number field matches the Sequence Number of an
outstanding Binding Revocation Indication that was sent by the outstanding Binding Revocation Indication that was sent by the
initiator. If the Sequence Number does not match any sequence number initiator. If the Sequence Number does not match any sequence number
of any of the outstanding BRI, the receiving node MUST ignore the of any of the outstanding BRI, the receiving node MUST ignore the
message but MAY log the event. message but MAY log the event.
6.3. Retransmission of Binding Revocation Indication 7.3. Retransmission of Binding Revocation Indication
If the sending mobility entity does not receive a Binding Revocation If the sending mobility entity does not receive a Binding Revocation
Acknowledgement in response to the outstanding Binding Revocation Acknowledgement in response to the outstanding Binding Revocation
Indication before the MINDelayBRIs timer expires, the mobility Indication before the MINDelayBRIs timer expires, the mobility
entity, e.g. LMA, may retransmit the same BRI message up to the entity, e.g. LMA, may retransmit the same BRI message up to the
BRIMaxRetriesNumber as defined in Section 11. If the revoking BRIMaxRetriesNumber as defined in Section 12. If the revoking
mobility entity does not receive a BRA message after the maximum mobility entity does not receive a BRA message after the maximum
number of retransmits have been sent, the revoking mobility entity number of retransmits have been sent, the revoking mobility entity
can clean the mobile node binding cache and all resources associated can clean the mobile node binding cache and all resources associated
with this binding. The revoking mobility entity may log the event. with this binding. The revoking mobility entity may log the event.
7. Home Agent Operation 8. Home Agent Operation
7.1. Sending Binding Revocation Indication 8.1. Sending Binding Revocation Indication
When an event requires the home agent to terminate a mobile node When an event requires the home agent to terminate a mobile node
mobile IPv6 registration, e.g. for administrative reason, the home mobile IPv6 registration, e.g. for administrative reason, the home
agent sends a Binding Revocation Indication message to the mobile agent sends a Binding Revocation Indication message to the mobile
node to inform the mobile node that its specified binding has been node to inform the mobile node that its specified binding has been
revoked and it will no longer be able to receive an IP connectivity revoked and it will no longer be able to receive an IP connectivity
via its binding with the home agent. via its binding with the home agent.
To terminate a mobile node registration and its current binding with To terminate a mobile node registration and its current binding with
the home agent, the home agent sends a packet to the mobile node the home agent, the home agent sends a packet to the mobile node
containing a Binding Revocation Indication, with the packet containing a Binding Revocation Indication, with the packet
constructed as follows: constructed as follows:
o The Acknowledge (A) bit MAY be set in the Binding Revocation o The Acknowledge (A) bit MAY be set in the BRI to request the
Indication to request the mobile node to send a Binding Revocation mobile node to send a Binding Revocation Acknowledgement upon
Acknowledgement upon receipt of the BRI. receipt of the BRI.
o The Revocation Trigger field MUST be set in the Binding Revocation o The Revocation Trigger field MUST be set in the Binding Revocation
Indication to indicate to the mobile node the reason for revoking Indication to indicate to the mobile node the reason for revoking
its IP mobility binding with the home agent. The Revocation its IP mobility binding with the home agent. The Revocation
Trigger may be used by the mobile node to take further steps if Trigger may be used by the mobile node to take further steps if
necessary. necessary.
o The packet MUST contain a Home Address destination option, which o The packet MUST contain a Home Address destination option, which
contains the mobile node's registered home address for the binding contains the mobile node's registered home address for the binding
being revoked. being revoked.
skipping to change at page 17, line 34 skipping to change at page 19, line 27
Address mobility option is included in the Binding Revocation Address mobility option is included in the Binding Revocation
Indication. Indication.
o The packet MAY contain a Home Address option which contains the o The packet MAY contain a Home Address option which contains the
mobile node's registered IPv4 home address for the binding being mobile node's registered IPv4 home address for the binding being
revoked. revoked.
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 6.3, the home agent SHOULD retransmit this Binding Revocation Section 7.3, the home agent SHOULD retransmit this Binding Revocation
Indication to the mobile node before terminating its IP connection Indication to the mobile node before terminating its IP connection
until it receives a matching Binding Revocation Acknowledgement or until it receives a matching Binding Revocation Acknowledgement or
the BRIMaxRetransmitNumber has been reached. the BRIMaxRetransmitNumber has been reached.
When the home agent send a Binding Revocation Indication to the When the home agent send a BRI to the mobile node, the home agent
mobile node, the home agent sets a flag in the mobile node BCE to sets a flag in the mobile node BCE to indicate that revocation is in
indicate that revocation is in progress and starts the MINDelayBRIs progress and starts the MINDelayBRIs timer. The home agent maintain
timer. The home agent maintain the mobile node BCE in this state the mobile node BCE in this state until it receives a Binding
until it receives a Binding Revocation Acknowledgement or the Revocation Acknowledgement or the BRIMaxRetransmitNumber is reached.
BRIMaxRetransmitNumber is reached.
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 use the mobile node home address
ID options that identify these bindings. In the case when the home in the Home Address destination option and include all the related
agent needs to revoke all of the mobile node bindings, the home agent Binding ID options that identify these bindings. In the case when
MUST use the mobile node home address in the Home Address destination the home agent needs to revoke all of the mobile node bindings, the
option and MUST NOT include any Binding ID option. home agent MUST use the mobile node home address in the Home Address
destination option and MUST NOT include any Binding ID option.
The home agent MUST use the IPsec security association as described The home agent MUST use the IPsec security association that has been
in [ID-MGSM] to secure the MGSM that carries the BRI and BRA messages used during the MIPv6 binding registration with the HA to secure the
transmission with the mobile node. BRI and BRA messages transmission with the mobile node.
7.2. Receiving Binding Revocation Acknowledgement 8.2. Receiving Binding Revocation Acknowledgement
When the home agent receives a packet carrying a valid Binding When the home agent receives a packet carrying a valid BRA that was
Revocation Acknowledgement that was successfully processed as in successfully processed as in Section 7.2, the home SHOULD examine the
Section 6.2, the home SHOULD examine the Status field as follows: 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 delete the Indication was processed successfully, the home agent delete the
MINDelayBRIs timer and the mobile node bindings and all related MINDelayBRIs timer and the mobile node bindings and all related
resources. resources.
o If the Status field indicates any value other than success, the o If the Status field indicates any value other than success, the
home agent SHOULD examine any mobility options included in the home agent SHOULD examine any mobility options included in the
Binding Revocation Acknowledgement. The home agent MAY log the Binding Revocation Acknowledgement. The home agent MAY log the
appropriate event to reflect the status of the received BRA. appropriate event to reflect the status of the received BRA.
8. Local Mobility Anchor Operation 9. Local Mobility Anchor Operation
8.1. Binding Revocation Initiator 9.1. Binding Revocation Initiator
8.1.1. Sending Binding Revocation Indication 9.1.1. Sending Binding Revocation Indication
When an event requires the local mobility agent to terminate a mobile When an event requires the local mobility agent to terminate a mobile
node proxy mobile IPv6 registration, e.g. for administrative reason node proxy mobile IPv6 registration, e.g. for administrative reason
or inter-MAG handover, the local mobility agent sends a Binding or inter-MAG handover, the local mobility agent sends a Binding
Revocation Indication message to the mobile access gateway which host Revocation Indication message to the mobile access gateway which host
the mobile node proxy CoA to indicate that the mobile node specified the mobile node proxy CoA to indicate that the mobile node specified
binding should be removed. It also indicate that the local mobility binding should be removed. It also indicate that the LMA will no
anchor will no longer maintain a tunnel for this mobile node binding longer maintain a tunnel for this mobile node binding which points to
which points to the mobile node proxy CoA that is hosted at this the mobile node proxy CoA that is hosted at this MAG.
mobile access gateway.
To terminate a mobile node proxy mobile IPv6 registration and its To terminate a mobile node proxy mobile IPv6 registration and its
current PMIPv6 binding with the local mobility agent, the local current PMIPv6 binding with the local mobility agent, the LMA sends a
mobility agent sends a packet to the mobile access gateway containing packet to the MAG containing a BRI message following the procedure in
a Binding Revocation Indication following the procedure in Section 7.1 and the following rules:
Section 6.1 and the following rules:
o The Acknowledge (A) bit MAY be set in the Binding Revocation o The Acknowledge (A) bit MAY be set in the Binding Revocation
Indication to request the mobile access gateway to send a Binding Indication to request the mobile access gateway to send a Binding
Revocation Acknowledgement upon receipt of the BRI. Revocation Acknowledgement upon receipt of the BRI.
o The Proxy Mobile IP (P) bit MUST be set in the Binding Revocation o The Proxy Mobile IP (P) bit MUST be set in the BRI message to
Indication to indicate that the binding being revoked is a proxy indicate that the binding being revoked is a proxy Mobile IPv6
Mobile IPv6 binding. binding.
o The Revocation Trigger field MUST be set in the Binding Revocation o The Revocation Trigger field MUST be set in the Binding Revocation
Indication to indicate to the mobile access gateway the reason for Indication to indicate to the mobile access gateway the reason for
removing the specified mobile node proxy mobile IPv6 binding at removing the specified mobile node proxy mobile IPv6 binding at
the local mobility anchor. The Revocation Trigger may be used by the LMA. The Revocation Trigger may be used by the mobile access
the mobile access gateway node to learn the mobile node latest gateway node to learn the mobile node latest movement.
movement.
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 mobile access gateway to remove all Per- Indication to request the mobile access gateway to remove all Per-
Peer bindings that are registered with the local mobility anchor Peer bindings that are registered with the LMA and hosted at this
and hosted at this mobile access gateway. MAG.
o Whenever the Global (G) bit is set in the BRI, the Acknowledge (A) o Whenever the Global (G) bit is set in the BRI, the Acknowledge (A)
bit MUST be set to request the mobile access gateway to send a bit MUST be set to request the mobile access gateway to send a
Binding Revocation Acknowledgement upon receipt of the BRI. Binding Revocation Acknowledgement upon receipt of the BRI.
o The packet MUST contain the Mobile Node Identifier, MN-ID, option o The packet MUST contain the Mobile Node Identifier, MN-ID, option
which contains the mobile node's NAI that was used in the Binding which contains the mobile node's NAI that was used in the proxy
Update during the mobile node registration. Binding Update during the mobile node registration.
o The packet MUST contain a Home Network Prefix option, which o The packet MUST contain a Home Network Prefix option, which
contains the mobile node's registered Home Network Prefix for the contains the mobile node's registered HNP for the binding being
binding being revoked. revoked.
o The care-of address for the binding MAY be used as the Source o The care-of address for the binding MAY be used as the Source
Address in the packet's IPv6 header, unless an Alternate Care-of Address in the packet's IPv6 header, unless an Alternate Care-of
Address mobility option is included in the Binding Revocation Address mobility option is included in the Binding Revocation
Indication. 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 6.3, the local mobility anchor SHOULD As described in Section 7.3, the LMA SHOULD retransmit this BRI to
retransmit this Binding Revocation Indication to the mobile access the MAG before deleting the mobile node IP tunnel to the mobile
gateway 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 before receiving the after sending the Binding Revocation Indication and before receiving
BRA message. the BRA message.
When the local mobility anchor send a Binding Revocation Indication When the local mobility anchor send a Binding Revocation Indication
to the mobile access gateway to remove a specific binding, the local to the mobile access gateway to remove a specific binding, the local
mobility anchor sets a flag in the mobile node proxy BCE to indicate mobility anchor sets a flag in the mobile node proxy BCE to indicate
that revocation is in progress and starts the MINDelayBRIs timer. that revocation is in progress and starts the MINDelayBRIs timer.
The local mobility anchor SHOULD maintain the mobile node proxy BCE The local mobility anchor SHOULD maintain the mobile node proxy BCE
in this state until it receives a Binding Revocation Acknowledgement in this state until it receives a Binding Revocation Acknowledgement
or the BRIMaxRetransmitNumber is reached. In the case when the local or the BRIMaxRetransmitNumber is reached. In the case when the local
mobility anchor sets the Revocation Trigger field to a value which mobility anchor sets the Revocation Trigger field to a value which
indicate inter-MAG handover, the local mobility anchor MAY switch the indicate inter-MAG handover, the local mobility anchor MAY switch the
mobile node IP tunnel to the target mobile access gateway before mobile node IP tunnel to the target mobile access gateway before
sending a Binding Revocation Indication to the sources mobile access sending a Binding Revocation Indication to the sources mobile access
gateway. gateway.
When the local mobility anchor needs to revoke all mobile nodes proxy When the local mobility anchor needs to revoke all mobile nodes proxy
BCE that are registered with the local mobility anchor and hosted at BCE that are registered with the local mobility anchor and hosted at
the mobile access gateway, the local mobility anchor MUST set the the mobile access gateway, the LMA MUST set the Global (G) bit and
Global (G) bit and the value of the Revocation Trigger field to Per- the value of the Revocation Trigger field to "Per-Peer Policy". In
Peer Policy. In this case, the local mobility anchor MUST NOT this case, the LMA MUST NOT include any mobility options in the BRI.
include any mobility options in the Binding Revocation Indication.
When the local mobility anchor needs to revoke all mobile nodes proxy When the LMA needs to revoke all mobile nodes proxy BCE that belong
BCE that belong to a specific realm, e.g. @companyabc.com, and are to a specific realm, e.g. @companyabc.com, and are registered with
registered with the local mobility anchor and hosted at the mobile the LMA and hosted at the MAG, the local mobility anchor MUST set the
access gateway, the local mobility anchor MUST set the Global (G) bit Global (G) bit and the value of the Revocation Trigger field to
and the value of the Revocation Trigger field to Local Policy. In "Revoking Node Local Policy". In this case, the local mobility
this case, the local mobility anchor MUST include a mobility option anchor MUST include a mobility option to identify the impacted
to identify the impacted bindings, e.g. MN-ID option with a wildcard bindings, e.g. MN-ID option with a wildcard NAI, e.g.
NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs *@companyabc.com, to identify all the mobile nodes BCEs that need to
that need to be removed. be removed.
When the mobile node is registered with multiple Home Network When the mobile node is registered with multiple Home Network
Prefixes for the same proxy care-of address, the local mobility Prefixes for the same proxy care-of address, the local mobility
anchor SHOULD include a Home Network Prefix option for each anchor SHOULD include a HNP option for each registered HNP in the
registered Home Network Prefix in the Binding Revocation Indication. BRI. Alternatively, the LMA MAY include only the mobile node
Alternatively, the local mobility anchor MAY include only the mobile identifier, MN-ID, option in the BRI to indicate to the mobile access
node identifier, MN-ID, option in the Binding Revocation Indication gateway to remove all bindings of the specified mobile node NAI in
to indicate to the mobile access gateway to remove all bindings of the MN-ID option.
the specified mobile node NAI in the MN-ID option.
8.1.2. Receiving Binding Revocation Acknowledgement When the mobile node is registered with an IPv4 proxy home address in
addition to the Home Network Prefix where both of the IPv4 pHoA and
HNP are bound to the same proxy CoA, the local mobility anchor MAY
revoke the mobile node IPv4 proxy HoA binding to the current mobile
node proxy CoA while maintaining the mobile node binding of the HNP
to its current pCoA as part of the mobile node BCE. In this case, if
the LMA decides to revoke the mobile node IPv4 proxy HoA ONLY, the
LMA MUST sends a BRI message following the procedure in Section 7.1
and the following rules:
o The Acknowledge (A) bit MUST be set in the BRI to request the MAG
to send a BRA message.
o The Revocation Trigger field MUST be set to "IPv4 HoA Binding
ONLY".
o The IPv4 Home Address option MUST be included with the mobile node
IPv4 home address that to be released in addition to the MN-ID
option.
o The mobile node HNP option MUST NOT be included.
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 6.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 Binding Revocation o If the Status field indicates that the BRI was processed
Indication was processed successfully, the local mobility anchor successfully, the local mobility anchor delete the MINDelayBRIs
delete the MINDelayBRIs timer and the mobile node proxy bindings timer and the mobile node proxy bindings and all associated
and all associated resources. resources.
o If the Status field indicates partial success value or MN binding o If the Status field indicates partial success value or MN binding
does not exist, the local mobility anchor SHOULD examine mobility does not exist, the local mobility anchor SHOULD examine mobility
options that included in the Binding Revocation Acknowledgement, options that are included in the Binding Revocation
if any, before deleting the MINDelayBRIs timer and the mobile node Acknowledgement, if any, before deleting the MINDelayBRIs timer
associated proxy bindings and all related resources. It is based and the mobile node associated proxy bindings and all related
on the local mobility anchor local policy how to handle the Mobile resources. It is based on the LMA local policy how to handle the
node BCE that the mobile access gateway indicated it failed the mobile node BCE(s) that the mobile access gateway indicated it
revocation procedure, however, the LMA MAY log the event. failed the revocation procedure, however, the LMA MAY log the
event.
8.2. Binding Revocation Responder 9.2. Binding Revocation Responder
8.2.1. Receiving Binding Revocation Indication 9.2.1. Receiving Binding Revocation Indication
When the local mobility anchor receives a packet carrying a Binding When the local mobility anchor receives a packet carrying a Binding
Revocation Indication that was successfully processed as in Revocation Indication that was successfully processed as in
Section 6.2, the local mobility anchor SHOULD in addition process the Section 7.2, the local mobility anchor SHOULD in addition process the
message as follows: message as follows:
o Binding Revocation Indication is formatted as in Section 5.1 and o Binding Revocation Indication is formatted as in Section 6.1 and
if the (P) bit is set, the local mobility anchor must validate if the (P) bit is set, the local mobility anchor MUST validate
that all the impacted bindings MUST have the proxy binding flag that all impacted binding(s) have the proxy binding flag set.
set.
o If the Global (G) bit is set, the Binding Revocation Indication o If the Global (G) bit is set, the BRI SHOULD contain the mobile
SHOULD contain the mobile access gateway ID in the MN-ID option. access gateway ID in the MN-ID option. The local mobility anchor
The local mobility anchor MUST verify that the identified mobile MUST verify that the identified mobile access gateway as per the
access gateway as per the value in the MN-ID option is authorized value in the MN-ID option is authorized to use the Per-Peer Global
to use the Per-Peer Global bindings revocation. The mechanism the bindings revocation. The mechanism the LMA uses to verify the MAG
local mobility anchor use to verify the mobile access gateway
authorization is out of scope of this document. When the (P) bit authorization is out of scope of this document. When the (P) bit
is set, this Binding Revocation Indication impact only the mobile is set, this Binding Revocation Indication impact only the mobile
nodes bindings that have the Proxy Mobile IP flag set. nodes bindings that have the Proxy Mobile IP flag set.
o The local mobility anchor identify all impacted mobile nodes o The LMA identify all impacted mobile nodes bindings and if the
bindings and if the Acknowledgement (A) bit is set, the local Acknowledgement (A) bit is set, the local mobility anchor MUST
mobility anchor MUST send a Binding Revocation Acknowledgement send a Binding Revocation Acknowledgement following Section 9.2.2
following Section 8.2.2 using the appropriate status code. using the appropriate status code.
o If the Global (G) bit is not set, the local mobility anchor MUST o If the Global (G) bit is not set, the local mobility anchor MUST
use the included mobility options to identify the impacted mobile use the included mobility options to identify the impacted mobile
node binding as follows: node binding as follows:
1. If only the mobile node identifier, MN-ID, option is included, 1. If only the mobile node identifier, MN-ID, option is included,
the local mobility anchor MUST revoke all bindings for this the local mobility anchor MUST revoke all bindings for this
mobile node which have a proxy CoA that is hosted at the mobile node which have a proxy CoA that is used as the source
mobile access gateway that sent the BRI. of the IPv6 packet that carried the BRI or in the Alternate
Care-of-Address option in the BRI.
2. If the mobile node identifier, MN-ID, and the Home Network 2. If the mobile node identifier, MN-ID, and the Home Network
Prefix option are included, the local mobility anchor MUST Prefix option are included, the local mobility anchor MUST
only remove the specified proxy binding. only remove the specified proxy binding.
3. If the mobile node identifier, MN-ID, option and more than one 3. If the mobile node identifier, MN-ID, option and more than one
Home Network Prefix options are included, the local mobility Home Network Prefix options are included, the local mobility
anchor need to remove the mobile node bindings which are anchor need to remove the mobile node bindings which are
referenced in these multiple Home Network Prefixes for the referenced in these multiple Home Network Prefixes for the
specified mobile node NAI. specified mobile node 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.
8.2.2. Sending Binding Revocation Acknowledgement 9.2.2. Sending Binding Revocation Acknowledgement
When the local mobility anchor receive a valid Binding Revocation When the local mobility anchor receive a valid Binding Revocation
Indication with the (A) bit is set and after processing the BRI Indication with the (A) bit is set and after processing the BRI
message, the local mobility anchor sends a packet to the mobile message, the local mobility anchor sends a packet to the mobile
access gateway containing a Binding Revocation Acknowledgement access gateway containing a Binding Revocation Acknowledgement
following the process in Section 6.1 and the following: following the process in Section 7.1 and the following:
o If the (P) bit was set in the received Binding Revocation o If the (P) bit was set in the received Binding Revocation
Indication, the local mobility anchor MUST set the (P) bit in the Indication, the local mobility anchor MUST set the (P) bit in the
Binding Revocation Acknowledgement. BRA.
o If the Global (G) bit was set in the received BRI, the local o If the Global (G) bit was set in the received BRI, the local
mobility anchor MUST set the (G) bit in the Binding Revocation mobility anchor MUST set the (G) bit in the Binding Revocation
Acknowledgement. Acknowledgement.
o The local mobility anchor MUST set the status field to a valid o The local mobility anchor MUST set the status field to a valid
code that reflects the processing of the received Binding code that reflects the processing of the received Binding
Revocation Indication. If the mobile access gateway is not Revocation Indication. If the mobile access gateway is not
authorized to use the Per-Peer Global revocation feature, the LMA authorized to use the Per-Peer Global revocation feature, the LMA
MUST set the status field to (Global Revocation NOT Authorized). MUST set the status field to (Global Revocation NOT Authorized).
o The local mobility MAY set the status field to partial success and o The LMA MAY set the status field to partial success and in this
in this case it MAY include the mobile node identifier or the Home case it MAY include the mobile node identifier or the Home Network
Network Prefix option to identify the bindings that failed Prefix option to identify the binding(s) that failed revocation.
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 BRI.
9. Mobile Access Gateway Operation 10. Mobile Access Gateway Operation
9.1. Binding Revocation Responder 10.1. Binding Revocation Responder
9.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 6.2 and the following: Section 7.2 and the following:
o Binding Revocation Indication MUST be formatted as in Section 5.1 o BRI MUST be formatted as in Section 6.1 and if the (P) bit is set,
and if the (P) bit is set, the mobile access gateway must validate the mobile access gateway must validate that the impacted binding
that the impacted binding have the proxy binding flag set. have the proxy binding flag set.
o If the Acknowledgement (A) bit in the received BRI is set, the o If the Acknowledgement (A) bit in the received BRI is set, the
mobile access gateway MUST send a Binding Revocation mobile access gateway MUST send a Binding Revocation
Acknowledgement following Section 9.1.2 using the appropriate Acknowledgement following Section 10.1.2 using the appropriate
status value. status value.
o If the Global (G) bit is set and the Revocation Trigger field is o If the Global (G) bit is set and the Revocation Trigger field is
set to Per-Peer policy, the mobile access gateway identify all set to "Per-Peer policy", the mobile access gateway identify all
bindings that are registered at the local mobility anchor and bindings that are registered at the LMA and hosted at the MAG.
hosted at the mobile access gateway. This Binding Revocation This Binding Revocation Indication does not include any other
Indication does not include any other mobility options. However, mobility options. However, if the (P) bit is set, this BRI MUST
if the (P) bit is set, this Binding Revocation Indication MUST
only impact mobile nodes bindings that have the Proxy Mobile IP only impact mobile nodes bindings that have the Proxy Mobile IP
flag set. flag set. In this case, the MAG MUST 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 is
set to Local policy, the mobile access gateway MUST identify all set to "Revoking Node Local Policy", the MAG MUST identify all
bindings that are registered at the local mobility anchor and bindings that are registered at the LMA and hosted at the MAG
hosted at the mobile access gateway using the mobility option using the mobility option(s) included in the BRI. This Binding
included in the Binding Revocation Indication. This Binding Revocation Indication SHOULD include at least the MN-ID option,
Revocation SHOULD include at least the MN-ID option, e.g. with a e.g. with a wild card NAI.
wild card NAI.
o If the Global (G) bit is set and the Revocation Trigger field is o If the Global (G) bit is set and the Revocation Trigger field is
set to Local policy, and no mobility options are included in the set to "Revoking Node Local Policy", and no mobility options are
Binding Revocation Indication message, the mobile access gateway included in the Binding Revocation Indication message, the MAG
MUST treat this as an error scenario. In this case, the mobile MUST treat this as an error scenario. In this case, the MAG
access gateway SHOULD send a Binding Revocation Acknowledgement SHOULD send a Binding Revocation Acknowledgement message with
message with status "CAN NOT Identify Binding". status "CAN NOT Identify Binding".
The Revocation Trigger field value in the received Binding Revocation o If the Revocation Trigger field in the received BRI message is set
Indication could be used by the mobile access gateway to define what to "Inter-MAG - Unknown Handoff", the MAG use the mobility
actions the mobile access gateway could do to inform the mobile node option(s) included in the BRI message to identify the mobile node
that its IP connectivity to the current Home Network Prefix has been binding and MUST validate that the mobile node is no longer
terminated. e.g. if the Revocation Trigger field is set to attached to the MAG before sending a successful BRA message and
administrative value, the mobile access gateway may send a RA message deleting the resources associated with the mobile node binding.
after setting the Home Network Prefix lifetime to zero.
o If the Revocation Trigger field in the received BRI message is set
to "IPv4 HoA Binding ONLY", the MAG uses the MN-ID option to
identify the mobile node binding entry in the BUL. The MAG MUST
verify that the IPv4 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 mobile node. After the MAG successfully
validate the received IPv4 home address as the mobile node IPv4
HoA, the MAG MUST consider this as an indication to release the
mobile node IPv4 proxy HoA binding to the mobile node current
proxy CoA ONLY. Consequently, the MAG MUST continue to maintain
the mobile node 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 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 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 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 Exist".
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
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
"Administrative Reason", the mobile access gateway may send a RA
message after setting the Home Network Prefix lifetime to zero.
If the Revocation Trigger field value in the received Binding If the Revocation Trigger field value in the received Binding
Revocation Indication message indicate an inter-MAG handover and the Revocation Indication message indicates an inter-MAG handover and the
(A) bit is set, the mobile access gateway MAY validate that the (A) bit is set, the mobile access gateway MAY validate that the
mobile node is no longer attached to the mobile access gateway before mobile node is no longer attached to the mobile access gateway before
sending a Binding Revocation Acknowledgement message to the local sending a successful Binding Revocation Acknowledgement message to
mobility anchor. the LMA. However, if the Revocation Trigger field is set to "Inter-
MAG - Unknown Handoff", 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.
9.1.2. Sending Binding Revocation Acknowledgement 10.1.2. Sending Binding Revocation Acknowledgement
When the mobile access gateway receive a valid Binding Revocation When the mobile access gateway receive a valid Binding Revocation
Indication with the (A) bit is set and after processing the BRI Indication with the (A) bit is set and after processing the BRI
message, the mobile access gateway sends a packet to the local message, the mobile access gateway sends a packet to the local
mobility anchor containing a Binding Revocation Acknowledgement mobility anchor containing a Binding Revocation Acknowledgement
according to the procedure in Section 6.1 and the following: according to the procedure in Section 7.1 and the following:
o The mobile access gateway MUST set the (P) bit in the Binding o The mobile access gateway MUST set the (P) bit in the Binding
Revocation Acknowledgement if it is set in the received BRI. Revocation Acknowledgement if it is set in the received BRI.
o If the Global (G) bit was set in the received BRI, the mobile o If the Global (G) bit was set in the received BRI, the mobile
access gateway MUST set the (G) bit in the Binding Revocation access gateway MUST set the (G) bit in the Binding Revocation
Acknowledgement. Acknowledgement.
o 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
skipping to change at page 25, line 9 skipping to change at page 27, line 44
o The mobile access gateway MAY set the status field to partial o The mobile access gateway MAY set the status field to partial
success and in this case it MAY include the mobile node success and in this case it MAY include the mobile node
identifier, MN-ID, or the Home Network Prefix option to identify identifier, MN-ID, or the Home Network Prefix option to identify
the binding(s) that failed to be removed as part of the revocation the binding(s) that failed to be removed as part of the revocation
procedure. procedure.
o The destination IP address of the IPv6 packet of the Binding o The destination IP address of the IPv6 packet of the Binding
Revocation Acknowledgement is set to the source IP address of the Revocation Acknowledgement is set to the source IP address of the
received Binding Revocation Indication. received Binding Revocation Indication.
9.2. Binding Revocation Initiator 10.2. Binding Revocation Initiator
9.2.1. Sending Binding Revocation Indication 10.2.1. Sending Binding Revocation Indication
The mobile access gateway send a Binding Revocation Indication when The mobile access gateway could send a Binding Revocation Indication
it needs to use global revocation, i.e. when the G bit is set. In message to indicate the termination of multiple mobile node bindings,
this case when an event occurs which requires the mobile access e.g., when using the global revocation with the Global (G) bit is
gateway to inform the local mobility anchor to terminate all mobile set. In this case when an event occurs which requires the mobile
nodes bindings that are registered at the local mobility anchor and access gateway to inform the LMA to terminate all mobile nodes
the mobile access gateway, the mobile access gateway send a Binding bindings that are registered at the local mobility anchor and the
Revocation Indication message following Section 6.1 and the mobile access gateway, the mobile access gateway sends a Binding
Revocation Indication message following Section 7.1 and the
following: 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 Mobile IP (P) bit MUST be set in the Binding Revocation
Indication to indicate that bindings that being revoked is a proxy Indication to indicate that bindings that being revoked is a proxy
Mobile IPv6 binding. Mobile IPv6 binding.
o The Global (G) bit MUST be set and the Revocation Trigger MUST o The Global (G) bit MUST be set and the Revocation Trigger contains
contain a value of Per-Peer Policy in the Binding Revocation a value of "Per-Peer Policy" in the Binding Revocation Indication
Indication to request the local mobility anchor to remove all Per- to request the LMA to remove all Per-Peer bindings that are
Peer bindings that are registered with the local mobility anchor registered with the LMA and hosted at this MAG. In this case, the
and hosted at this mobile access gateway. In this case, the MN-ID option MUST be included in the BRI and contains the mobile
mobile node identifier, MN-ID, option MUST be included in the BRI access gateway identity.
and MUST contain the mobile access gateway identity
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 BRA in response to this Binding
Acknowledgement in response to this Binding Revocation Indication. Revocation Indication. As described in Section 7.3, the mobile
As described in Section 6.3, the mobile access gateway SHOULD access gateway SHOULD retransmit this BRI to the local mobility
retransmit this Binding Revocation Indication to the local mobility anchor until it receives a matching BRA or the BRIMaxRetransmitNumber
anchor until it receives a matching Binding Revocation is reached. The mobile access gateway MAY delete the mobile nodes IP
Acknowledgement or the BRIMaxRetransmitNumber is reached. The mobile tunnels immediately after sending the Binding Revocation Indication
access gateway MAY delete the mobile nodes IP tunnels immediately before receiving a BRA message from the LMA.
after sending the Binding Revocation Indication before receiving a
BRA message from the LMA.
9.2.2. Receiving Binding Revocation Acknowledgement 10.2.2. Receiving Binding Revocation Acknowledgement
When the mobile access gateway receive a packet carrying a valid When the mobile access gateway receive a packet carrying a valid
Binding Revocation Acknowledgement that was successfully processed Binding Revocation Acknowledgement that was successfully processed
according to Section 6.2, the mobile access gateway MUST validate the according to Section 7.2, the mobile access gateway MUST validate the
BRA as per the followings: BRA as per the followings:
o When the mobile access gateway receive a packet carrying a valid o When the mobile access gateway receive a packet carrying a valid
Binding Revocation Acknowledgement and the Global (G) and Proxy Binding Revocation Acknowledgement and the Global (G) and Proxy
MIPv6 (P) bits are set and the mobile nodes BCEs are in the state MIPv6 (P) bits are set and the mobile nodes BCEs are in the state
of Revocation in Progress, the mobile access gateway SHOULD of Revocation in Progress, the mobile access gateway SHOULD
examine the Status field as follows: examine the Status field as follows:
o If the Status field indicates that the Binding Revocation o If the Status field indicates that the Binding Revocation
Indication was processed successfully, the mobile access gateway Indication was processed successfully, the mobile access gateway
skipping to change at page 26, line 31 skipping to change at page 29, line 18
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 is 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.
10. Mobile Node Operation 11. Mobile Node Operation
10.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 6.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 Home o The mobile node MUST verify that the IP address in the Home
Address option is its Home Address. Address option is its Home Address.
o If the Acknowledgement (A) bit is set in the Binding Revocation o If the Acknowledgement (A) bit is set in the Binding Revocation
Indication and the MN has the BCE in registered state, the mobile Indication and the MN has the BCE in registered state, the mobile
node MUST send a Binding Revocation Acknowledgement. However, in node MUST send a Binding Revocation Acknowledgement. However, in
all other cases when the (A) bit is set in the BRI, the mobile all other cases when the (A) bit is set in the BRI, the mobile
node SHOULD send a Binding Revocation Acknowledgement. In all node SHOULD send a Binding Revocation Acknowledgement. In all
cases, the mobile node MUST follow Section 10.2 when send a BRA cases, the mobile node MUST follow Section 11.2 when send a BRA
using the appropriate status code. using the appropriate status code.
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. Indication message.
o If the Revocation Trigger field value is Administrative, the o If the Revocation Trigger field value is "Administrative Reason",
mobile node MUST not try to re-register with the home agent before the mobile node MUST not try to re-register with the home agent
contacting its home operator. before contacting its home operator.
o If the mobile node has registered multiple care-of addresses with o If the mobile node has registered multiple care-of addresses with
its home agent, the mobile node MUST verify which binding is being its home agent, the mobile node MUST verify which binding is being
revoked by examining the content of the BRI message. If the revoked by examining the content of the BRI message. If the
mobile node received a Binding Revocation Indication with a single mobile node received a Binding Revocation Indication with a single
or more than one BID options and its home address is in the Home or more than one BID options and its home address is in the Home
Address option, the mobile node MUST consider its bindings Address option, the mobile node MUST consider its bindings
identified in the Binding ID options are being revoked. identified in the Binding ID options are being revoked.
o If the mobile node has multi Care-of Addresses bindings with its o If the mobile node has multi Care-of Addresses bindings with its
home agent and received a Binding Revocation Indication, with only home agent and received a Binding Revocation Indication, with only
its home address in the Home Address option, the mobile node MUST its home address in the Home Address option, the mobile node MUST
consider all of its registered care-of addresses bindings with consider all of its registered care-of addresses bindings with
this home address have been revoked. this home address have been 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.
10.2. Sending Binding Revocation Acknowledgement 11.2. Sending Binding Revocation Acknowledgement
When the mobile node receive a valid Binding Revocation Indication When the mobile node receive a valid Binding Revocation Indication
with the (A) bit is set from its home agent and while having this BCE with the (A) bit is set from its home agent and while having this BCE
in registered state, the mobile node MUST send a packet to its home in registered state, the mobile node MUST send a packet to its home
agent containing a Binding Revocation Acknowledgement according to agent containing a Binding Revocation Acknowledgement according to
the procedure in Section 6.1 and the following: the procedure in Section 7.1 and the following:
o The mobile node MUST set the status field to successful to reflect o The mobile node MUST set the status field to successful to reflect
that it has received the Binding Revocation Indication and that it has received the Binding Revocation Indication and
acknowledge that its IP connectivity with its home agent has been acknowledge that its IP connectivity with its home agent has been
revoked. revoked.
o The destination IP address of the IPv6 packet of the Binding o The destination IP address of the IPv6 packet of the Binding
Revocation Acknowledgement is set to the source IP address of the Revocation Acknowledgement is set to the source IP address of the
received Binding Revocation Indication. received Binding Revocation Indication.
o If the mobile node receive a Binding Revocation Indication from a o If the mobile node receives a Binding Revocation Indication from a
home agent which the mobile node does not have a registered home agent which the mobile node does not have a registered
binding with, the mobile node SHOULD silently discard the BRI binding with, the mobile node SHOULD silently discard the BRI
message. The mobile node should continue to use its assigned HoA message. The mobile node should continue to use its assigned HoA
to access its IP mobility service. to access its IP mobility service.
11. Protocol Configuration Variables 12. Protocol Configuration Variables
Any mobility entity which is allowed to invoke the binding revocation Any mobility entity which is allowed to invoke the binding revocation
procedure by sending a Binding Revocation Indication message SHOULD procedure by sending a Binding Revocation Indication message SHOULD
allow the following variables to be configured. allow the following variables to be configured.
BRI Maximum Number of Retries (BRIMaxRetriesNumber) BRI Maximum Number of Retries (BRIMaxRetriesNumber)
This variable specifies the maximum Number of times a mobility This variable specifies the maximum Number of times a mobility
entity can retransmit a Binding Revocation Indication message entity can retransmit a Binding Revocation Indication message
before receiving a Binding Revocation Acknowledgement message. before receiving a Binding Revocation Acknowledgement message.
The default value for this parameter is 1. The default value for this parameter is 1.
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.
12. IANA Considerations 13. IANA Considerations
This document defines two new messages BRI and BRA, as described in This document defines two new messages BRI and BRA, as described in
Section 5.1 and Section 5.2 by using two subtypes of the Mobile IPv6 Section 6.1 and Section 6.2 by using Binding Revocation types of 1
Generic Signalling Message which uses a MH type <TBD-IANA> as in and 2 of the Binding Revocation Message which is defined in in
[ID-MGSM] which requires the use of IPsec, The new subtype values Section 6 and uses a MH type <IANA-TBD>. The new Mobility Header
<IANA-SUB1 and IANA-SUB2> needs to be assigned from the same type value needs to be assigned from the same numbering space as
numbering space as allocated for the other MGSM subtypes. allocated for the other Mobility Header types.
13. Security Considerations 14. Security Considerations
The protocol described here uses the same security association The protocol described here uses the same security association
between the MN and the HA or the MAG and the LMA that has been used between the MN and the HA or the MAG and the LMA that has been used
to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the to exchange the corresponding MIPv6 or Proxy MIPv6 BU and BA when the
session was established. If IPsec is used, The SPD of this IPsec SA session was established. If IPsec is used, The SPD of this IPsec SA
MUST allow the MH type for the MGSM. MUST allow the MH type for the Binding Revocation Message defined in
this document.
However, in the case when the MAG sends a BRI message with the G bit However, in the case when the MAG sends a BRI message with the Global
is set, the LMA MUST verify that the MAG is authorized to use Per- (G) bit is set, the LMA MUST verify that the MAG is authorized to use
Peer Global Revocation. Per-Peer Global Revocation.
14. Acknowledgements 15. Acknowledgements
The authors would like to thank Ryuji Wakikawa, Bruno Mongazon- The authors would like to thank Ryuji Wakikawa, Bruno Mongazon-
Cazavet and Domagoj Premec for their review and comments of this Cazavet, Domagoj Premec for their review and comments of this draft
draft and all colleagues who have supported the advancement of this and all colleagues who have supported the advancement of this draft
draft effort. effort.
15. References 16. References
15.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-04 (work in Routers", draft-ietf-mext-nemo-v4traversal-04 (work in
progress), June 2008. progress), June 2008.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration", "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-08 (work in progress), draft-ietf-monami6-multiplecoa-08 (work in progress),
May 2008. May 2008.
[ID-MGSM] Haley, B. and S. Gundavelli, "Mobile IPv6 Generic
Signaling Message",
draft-haley-mext-generic-signaling-message-00 (work in
progress), July 2008.
[ID-PMIP6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-18 (work in progress),
May 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-03 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03
(work in progress), May 2008. (work in progress), May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
15.2. Informative References [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
16.2. Informative References
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003. Mobile IPv4", RFC 3543, August 2003.
Authors' Addresses Authors' Addresses
Ahmad Muhanna Ahmad Muhanna
 End of changes. 154 change blocks. 
463 lines changed or deleted 560 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/