draft-ietf-mext-binding-revocation-07.txt   draft-ietf-mext-binding-revocation-08.txt 
Network Working Group A. Muhanna Network Working Group A. Muhanna
Internet-Draft M. Khalil Internet-Draft M. Khalil
Intended status: Standards Track Nortel Intended status: Standards Track Nortel
Expires: December 16, 2009 S. Gundavelli Expires: February 13, 2010 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Startent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
June 14, 2009 August 12, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-07.txt draft-ietf-mext-binding-revocation-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 16, 2009. This Internet-Draft will expire on February 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 17 skipping to change at page 3, line 7
This document defines a binding revocation mechanism to terminate a This document defines a binding revocation mechanism to terminate a
mobile node's mobility session and the associated resources. These mobile node's mobility session and the associated resources. These
semantics are generic enough and can be used by mobility entities in semantics are generic enough and can be used by mobility entities in
the case of Mobile IPv6 and its extensions. This mechanism allows the case of Mobile IPv6 and its extensions. This mechanism allows
the mobility entity which initiates the revocation procedure to the mobility entity which initiates the revocation procedure to
request its corresponding one to terminate either one, multiple or request its corresponding one to terminate either one, multiple or
all specified binding cache entries. all specified binding cache entries.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5
2.1. Conventions used in this document . . . . . . . . . . . . 4 2.1. Conventions used in this document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Binding Revocation Protocol and Use Cases Overview . . . . . . 4 3. Binding Revocation Protocol and Use Cases Overview . . . . . . 5
3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 5 3.1. Binding Revocation Protocol . . . . . . . . . . . . . . . 6
3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 6 3.2. MIPv6 and DSMIP6 Use Case . . . . . . . . . . . . . . . . 7
3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 7 3.3. Multi-Care of Addresses (Monami6) Use Case . . . . . . . . 8
3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 8 3.4. Proxy MIPv6 Use Case . . . . . . . . . . . . . . . . . . . 9
3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding 3.4.1. Local Mobility Anchor Initiates PMIPv6 Binding
Revocation . . . . . . . . . . . . . . . . . . . . . . 9 Revocation . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 10 3.4.2. Mobile Access Gateway Revokes Bulk PMIPv6 Bindings . . 11
4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Security Model . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Binding Revocation Messages over IPv4 Transport Network . . . 11 5. Binding Revocation Messages over IPv4 Transport Network . . . 12
6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 11 6. Binding Revocation Message . . . . . . . . . . . . . . . . . . 13
6.1. Binding Revocation Indication Message . . . . . . . . . . 12 6.1. Binding Revocation Indication Message . . . . . . . . . . 14
6.2. Binding Revocation Acknowledgement Message . . . . . . . . 16 6.2. Binding Revocation Acknowledgement Message . . . . . . . . 17
7. Binding Revocation Process Operation . . . . . . . . . . . . . 18 7. Binding Revocation Process Operation . . . . . . . . . . . . . 20
7.1. Sending Binding Revocation Messages . . . . . . . . . . . 18 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 20
7.2. Receiving Binding Revocation Messages . . . . . . . . . . 19 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 20
7.3. Retransmission of Binding Revocation Indication . . . . . 20 7.3. Retransmission of Binding Revocation Indication . . . . . 22
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 20 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 22
8.1. Sending Binding Revocation Indication . . . . . . . . . . 20 8.1. Sending Binding Revocation Indication . . . . . . . . . . 22
8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 22 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 23
9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 22 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 24
9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 22 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 24
9.1.1. Sending Binding Revocation Indication . . . . . . . . 22 9.1.1. Sending Binding Revocation Indication . . . . . . . . 24
9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 26 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 28
9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 27 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 29
9.2.1. Receiving Binding Revocation Indication . . . . . . . 27 9.2.1. Receiving Binding Revocation Indication . . . . . . . 29
9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 28 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 30
10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 29 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 31
10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 29 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 31
10.1.1. Receiving Binding Revocation Indication . . . . . . . 29 10.1.1. Receiving Binding Revocation Indication . . . . . . . 31
10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 31 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 33
10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 31 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 33
10.2.1. Sending Binding Revocation Indication . . . . . . . . 32 10.2.1. Sending Binding Revocation Indication . . . . . . . . 33
10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 33 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 34
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 33 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 35
11.1. Receiving Binding Revocation Indication . . . . . . . . . 33 11.1. Receiving Binding Revocation Indication . . . . . . . . . 35
11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 35 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 36
12. Protocol Configuration Variables . . . . . . . . . . . . . . . 35 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
14. Security Considerations . . . . . . . . . . . . . . . . . . . 37 14. Security Considerations . . . . . . . . . . . . . . . . . . . 39
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
16.1. Normative References . . . . . . . . . . . . . . . . . . . 38 16.1. Normative References . . . . . . . . . . . . . . . . . . . 40
16.2. Informative References . . . . . . . . . . . . . . . . . . 38 16.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
In the case of Mobile IPv6 and for administrative reason, sometimes In the case of Mobile IPv6 and for administrative reason, sometimes
it becomes necessary to inform the mobile node that its registration it becomes necessary to inform the mobile node that its registration
has been revoked and the mobile node is no longer able to receive IP has been revoked and the mobile node is no longer able to receive IP
mobility service using its Home Address. A similar Mobile IPv4 mobility service using its Home Address. A similar Mobile IPv4
registration revocation mechanism [RFC3543] has been specified by registration revocation mechanism [RFC3543] has been specified by
IETF for providing a revocation mechanism for sessions that were IETF for providing a revocation mechanism for sessions that were
established using Mobile IPv4 registration [RFC3344]. established using Mobile IPv4 registration [RFC3344].
skipping to change at page 11, line 31 skipping to change at page 12, line 31
Additionally, in the case when the local mobility anchor receives a Additionally, in the case when the local mobility anchor receives a
Binding Revocation Indication which indicates a bulk termination Binding Revocation Indication which indicates a bulk termination
where the (G) bit is set and the Revocation Trigger field is set to where the (G) bit is set and the Revocation Trigger field is set to
"Per-Peer Policy", the local mobility anchor MUST verify that the "Per-Peer Policy", the local mobility anchor MUST verify that the
mobile access gateway sending the binding revocation indication mobile access gateway sending the binding revocation indication
message is authorized to invoke global revocation. message is authorized to invoke global revocation.
5. Binding Revocation Messages over IPv4 Transport Network 5. Binding Revocation Messages over IPv4 Transport Network
In some deployments, the network between the mobile access gateway In some deployments, the network between the mobile access gateway
and the local mobility anchor may only support IPv4 transport. In and the local mobility anchor may only support IPv4 transport.
this case, the Binding Revocation messages (BRI and BRA) are tunneled Another case is when a mobile node which support client mobile IPv6
over IPv4. If the Proxy Binding Update and Proxy Binding roam to an access network where only IPv4 addressing and transport is
Acknowledgment messages are sent using UDP encapsulation to traverse supported. In this case, the mobile node is required to register an
NATs, then the Binding Revocation messages are sent using the same IPv4 home address with its home agent using a mobile IPv6 Binding
UDP encapsulation. The same UDP port that was used for exchanging Update message.
the Proxy Binding Update and Proxy Binding Acknowledgement messages
will also be used when transporting Binding Revocation messages over If the Proxy Binding Update and Proxy Binding Acknowledgment messages
IPv4 using UDP encapsulation. In other words, the destination UDP or the Binding Update and Binding Acknowledgement messages are sent
port of the Binding Revocation Indication message MUST be set to the using UDP encapsulation to traverse NATs, then the Binding Revocation
source UDP port of the latest successfully processed Proxy Binding messages are sent using the same UDP encapsulation. The same UDP
Update message which is already saved in the mobile node BCE. For port that was used for exchanging the Proxy Binding Update and Proxy
more details on tunneling Proxy Mobile IPv6 signaling messages over Binding Acknowledgement or the Binding Update and Binding
IPv4, see [ID-PMIP6-IPv4]. Acknowledgement messages will also be used when transporting Binding
Revocation messages over IPv4 using UDP encapsulation. In other
words, the destination UDP port of the Binding Revocation Indication
message MUST be set to the source UDP port of the latest successfully
processed Proxy Binding Update or Binding Update message which is
already saved in the mobile node BCE. For more details on tunneling
Proxy Mobile IPv6 and Mobile IPv6 signaling messages over IPv4, see
[ID-PMIP6-IPv4] and [RFC5555], respectively.
6. Binding Revocation Message 6. Binding Revocation Message
This section defines the Binding Revocation Message format using a MH This section defines the Binding Revocation Message format using a MH
Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding Type <IANA-TBD> as illustrated in Figure 4. The value in the Binding
Revocation Type field defines whether the Binding Revocation message Revocation Type field defines whether the Binding Revocation message
is a Binding Revocation Indication or Binding Revocation is a Binding Revocation Indication or Binding Revocation
Acknowledgement. If the Binding Revocation type field is set to 1, Acknowledgement. If the Binding Revocation type field is set to 1,
the Binding Revocation Message is a Binding Revocation Indication as the Binding Revocation Message is a Binding Revocation Indication as
in Section 6.1. However, if the value is 2, it is a Binding in Section 6.1. However, if the value is 2, it is a Binding
skipping to change at page 12, line 24 skipping to change at page 13, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | B.R. Type | | | Checksum | B.R. Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. Binding Revocation Message Data . . Binding Revocation Message Data .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Binding Revocation Message Figure 4: Binding Revocation Message
MH Type
<IANA-TBD> which identifies the mobility message as a Binding
Revocation message.
Reserved
8-bit field reserved for future use. The value MUST be
initialized to zero by the sender, and MUST be ignored by the
receiver.
Checksum
16-bit unsigned integer. This field contains the checksum of the
Mobility Header. The checksum is calculated as described in
[RFC3775].
Binding Revocation Type Binding Revocation Type
8-bit unsigned integer. It defines the type of Binding Revocation 8-bit unsigned integer. It defines the type of the Binding
Message. It can be assigned one of the following values: Revocation Message. It can be assigned one of the following
values:
0 Reserved 0 Reserved
1 Binding Revocation Indication Message 1 Binding Revocation Indication Message
2 Binding Revocation Acknowledgement Message 2 Binding Revocation Acknowledgement Message
All other values are reserved All other values are reserved
Binding Revocation Message Data Binding Revocation Message Data
The Binding Revocation Message Data follows the Binding Revocation The Binding Revocation Message Data follows the Binding Revocation
Message format that is defined in this document for the specified Message format that is defined in this document for the specified
skipping to change at page 19, line 32 skipping to change at page 21, line 15
Mobility Headers test check, the receiving node MUST follow the Mobility Headers test check, the receiving node MUST follow the
processing rules as in Section 9.2 of [RFC3775]. If the receiving processing rules as in Section 9.2 of [RFC3775]. If the receiving
node does not support the Binding Revocation Indication message and node does not support the Binding Revocation Indication message and
does not recognize the new MH type, it sends a Binding Error message does not recognize the new MH type, it sends a Binding Error message
with the Status field set to 2 as described in [RFC3775]. with the Status field set to 2 as described in [RFC3775].
Since some mobility entities, e.g., local mobility anchor and mobile Since some mobility entities, e.g., local mobility anchor and mobile
access gateway, are allowed to receive and possibly send a Binding access gateway, are allowed to receive and possibly send a Binding
Revocation Indication or Binding Revocation Acknowledgement for Revocation Indication or Binding Revocation Acknowledgement for
different cases, therefore, if IPsec is used to secure signaling different cases, therefore, if IPsec is used to secure signaling
between the them, it prevents any possible man in the middle between the local mobility anchor and mobile access gateway, it
reflection attack. prevents any of them from processing a Binding Revocation message
that was not constructed by an authorized party.
Upon receiving a packet carrying a Binding Revocation Indication or Upon receiving a packet carrying a Binding Revocation Indication or
Binding Revocation Acknowledgement, the receiving mobility entity Binding Revocation Acknowledgement, the receiving mobility entity
verifies that the packet was received protected with the security verifies that the packet was received protected with the security
association that has been used during the binding registration association that has been used during the binding registration
signaling phase, e.g., an IPsec SA. signaling phase, e.g., an IPsec SA.
Upon receiving a packet carrying a Binding Revocation Upon receiving a packet carrying a Binding Revocation
Acknowledgement, the receiving mobility entity, initiator, MUST Acknowledgement, the receiving mobility entity, initiator, MUST
validate that sequence number in the Sequence Number field matches validate that sequence number in the Sequence Number field matches
skipping to change at page 20, line 25 skipping to change at page 22, line 10
Revocation Indication message intent, e.g., the Global Revocation (G) Revocation Indication message intent, e.g., the Global Revocation (G)
bit set and the Revocation Trigger field vale is a per-MN specific, bit set and the Revocation Trigger field vale is a per-MN specific,
the receiving mobility node SHOULD reject the Binding Revocation the receiving mobility node SHOULD reject the Binding Revocation
Indication message by sending a Binding Revocation Acknowledgement Indication message by sending a Binding Revocation Acknowledgement
message with the Status field set to "Revocation Function NOT message with the Status field set to "Revocation Function NOT
Supported". Supported".
7.3. Retransmission of Binding Revocation Indication 7.3. Retransmission of Binding Revocation Indication
If the sending mobility entity does not receive a Binding Revocation If the sending mobility entity does not receive a Binding Revocation
Acknowledgement in response to the outstanding Binding Revocation Acknowledgement in response to the outstanding initial Binding
Indication before the MINDelayBRIs timer expires, the mobility Revocation Indication before the InitMINDelayBRIs timer expires, the
entity, e.g. LMA, may retransmit the same BRI message up to the mobility entity, e.g. LMA, SHOULD retransmit the same BRI message up
BRIMaxRetriesNumber as defined in Section 12. If the revoking to the BRIMaxRetriesNumber as defined in Section 12.
mobility entity does not receive a Binding Revocation Acknowledgement
message after the maximum number of retransmits have been sent, the The retransmissions by the sending mobility entity MUST use an
revoking mobility entity can clean the mobile node binding cache and exponential back-off process in which the timeout period is doubled
all resources associated with this binding. The revoking mobility upon each retransmission, until either the node receives a response
entity may log the event. or the timeout period reaches the value MAX_BRACK_TIMEOUT. The
sending mobility entity MAY continue to send these messages at this
slower rate up to the BRIMaxRetriesNumber.
If the revoking mobility entity does not receive a Binding Revocation
Acknowledgement message after the maximum number of retransmits have
been sent, the revoking mobility entity can clean the mobile node
binding cache and all resources associated with this binding. The
revoking mobility entity may log the event.
8. Home Agent Operation 8. Home Agent Operation
8.1. Sending Binding Revocation Indication 8.1. Sending Binding Revocation Indication
To terminate a mobile node registration and its current binding with To terminate a mobile node registration and its current binding with
the home agent, the home agent sends a packet to the mobile node the home agent, the home agent sends a packet to the mobile node
containing a Binding Revocation Indication, with the packet containing a Binding Revocation Indication, with the packet
constructed as follows: constructed as follows:
skipping to change at page 21, line 35 skipping to change at page 23, line 26
the mobile node to return a Binding Revocation Acknowledgement in the mobile node to return a Binding Revocation Acknowledgement in
response to this Binding Revocation Indication. As described in response to this Binding Revocation Indication. As described in
Section 7.3, the home agent SHOULD retransmit this Binding Revocation Section 7.3, the home agent SHOULD retransmit this Binding Revocation
Indication to the mobile node before terminating its IP connection Indication to the mobile node before terminating its IP connection
until it receives a matching Binding Revocation Acknowledgement or until it receives a matching Binding Revocation Acknowledgement or
the BRIMaxRetransmitNumber has been reached. the BRIMaxRetransmitNumber has been reached.
When the home agent sends a Binding Revocation Indication to the When the home agent sends a Binding Revocation Indication to the
mobile node with the (A) bit set, the home agent sets a flag in the mobile node with the (A) bit set, the home agent sets a flag in the
mobile node BCE to indicate that revocation is in progress and starts mobile node BCE to indicate that revocation is in progress and starts
the MINDelayBRIs timer. The home agent maintains the mobile node BCE the InitMINDelayBRIs timer. The home agent maintains the mobile node
in this state until it receives a Binding Revocation Acknowledgement BCE in this state until it receives a Binding Revocation
or the BRIMaxRetransmitNumber is reached. Acknowledgement or retransmits the Binding Revocation Indication
message as described in Section 7.3.
In a race condition case, the home agent may receive a Binding Update In a race condition case, the home agent may receive a Binding Update
from the mobile node while the mobile node's BCE has the revocation from the mobile node while the mobile node's BCE has the revocation
in progress flag set, the home agent SHOULD handle this case based on in progress flag set, the home agent SHOULD handle this case based on
the reason for sending the Binding Revocation Indication message and the reason for sending the Binding Revocation Indication message and
its local policy. In this case, if the home agent accepts the its local policy. In this case, if the home agent accepts the
Binding Update, it needs to update the mobile node BCE accordingly, Binding Update, it needs to update the mobile node BCE accordingly,
e.g. removing the revocation in progress flag. e.g. removing the revocation in progress flag.
When the home agent needs to revoke one or more of a mobile node When the home agent needs to revoke one or more of a mobile node
skipping to change at page 22, line 16 skipping to change at page 24, line 8
8.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 Binding
Revocation Acknowledgement that was successfully processed as in Revocation Acknowledgement that was successfully processed as in
Section 7.2, the home agent SHOULD examine the Status field as Section 7.2, the home agent SHOULD examine the Status field as
follows: follows:
o If the Status field indicates that the Binding Revocation o If the Status field indicates that the Binding Revocation
Indication was processed successfully, the home agent deletes the Indication was processed successfully, the home agent deletes the
MINDelayBRIs timer and the mobile node bindings and all related current 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 received status. appropriate event to reflect the received status.
9. Local Mobility Anchor Operation 9. Local Mobility Anchor Operation
9.1. Binding Revocation Initiator 9.1. Binding Revocation Initiator
skipping to change at page 23, line 48 skipping to change at page 25, line 37
it receives a matching Binding Revocation Acknowledgement or the it receives a matching Binding Revocation Acknowledgement or the
BRIMaxRetransmitNumber is reached. The local mobility anchor MAY BRIMaxRetransmitNumber is reached. The local mobility anchor MAY
delete the mobile node(s) IP tunnel immediately after sending the delete the mobile node(s) IP tunnel immediately after sending the
Binding Revocation Indication and before receiving the Binding Binding Revocation Indication and before receiving the Binding
Revocation Acknowledgement message. Revocation Acknowledgement message.
When the local mobility anchor sends a Binding Revocation Indication When the local mobility anchor sends a Binding Revocation Indication
to the mobile access gateway to remove a specific binding and the to the mobile access gateway to remove a specific binding and the
Acknowledge (A) bit is set, the local mobility anchor sets a flag in Acknowledge (A) bit is set, the local mobility anchor sets a flag in
the mobile node proxy BCE to indicate that revocation is in progress the mobile node proxy BCE to indicate that revocation is in progress
and starts the MINDelayBRIs timer. The local mobility anchor SHOULD and starts the InitMINDelayBRIs timer. The local mobility anchor
maintain the mobile node proxy BCE in this state until it receives a SHOULD maintain the mobile node proxy BCE in this state until it
Binding Revocation Acknowledgement or the BRIMaxRetransmitNumber is receives a Binding Revocation Acknowledgement or the
reached. In the case when the local mobility anchor sets the BRIMaxRetransmitNumber is reached. In the case when the local
Revocation Trigger field to a value which indicates inter-MAG mobility anchor sets the Revocation Trigger field to a value which
handover, the local mobility anchor MAY switch the mobile node IP indicates inter-MAG handover, the local mobility anchor MAY switch
tunnel to the target mobile access gateway before sending the Binding the mobile node IP tunnel to the target mobile access gateway before
Revocation Indication to the source mobile access gateway. sending the Binding Revocation Indication to the source mobile access
gateway.
In a race condition case, the local mobility anchor may receive a In a race condition case, the local mobility anchor may receive a
Proxy Binding Update from the mobile access gateway while the mobile Proxy Binding Update from the mobile access gateway while the mobile
node's proxy BCE has the revocation in progress flag set, the local node's proxy BCE has the revocation in progress flag set, the local
mobility anchor should handle this case based on the reason for mobility anchor should handle this case based on the reason for
sending the Binding Revocation Indication message and its local sending the Binding Revocation Indication message and its local
policy. In this case, if the local mobility anchor accepts the Proxy policy. In this case, if the local mobility anchor accepts the Proxy
Binding Update, it needs to update the mobile node proxy BCE Binding Update, it needs to update the mobile node proxy BCE
accordingly, e.g. removing the revocation in progress flag. accordingly, e.g. removing the revocation in progress flag.
When the local mobility anchor needs to revoke all mobile nodes proxy When the local mobility anchor needs to revoke all mobile nodes proxy
BCE that are registered with the local mobility anchor and hosted at BCE that are registered with the local mobility anchor and hosted at
the mobile access gateway, it MUST set the Global (G) bit and set the the mobile access gateway, it MUST set the Global (G) bit and set the
value of the Revocation Trigger field to "Per-Peer Policy". In this value of the Revocation Trigger field to "Per-Peer Policy". In this
case, the local mobility anchor MUST NOT include any mobility options case, the local mobility anchor MUST NOT include any mobility options
in the this Binding Revocation Indication message. in the this Binding Revocation Indication message.
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 belong to a specific realm, e.g. @companyabc.com, that are BCE that belong to a specific realm, e.g. @example.com, that are
registered with the local mobility anchor and hosted at the mobile registered with the local mobility anchor and hosted at the mobile
access gateway, the local mobility anchor MUST set the Global (G) bit access gateway, the local mobility anchor MUST set the Global (G) bit
and set the value of the Revocation Trigger field to "Revoking and set the value of the Revocation Trigger field to "Revoking
Mobility Node Local Policy". In this case, the local mobility anchor Mobility Node Local Policy". In this case, the local mobility anchor
MUST include a mobility option in the Binding Revocation Indication MUST include a mobility option in the Binding Revocation Indication
to identify the impacted bindings, e.g., MN-ID option with a wildcard to identify the impacted bindings, e.g., MN-ID option with an NAI
NAI, e.g. *@companyabc.com, to identify all the mobile nodes BCEs value of @example.com, to identify all the mobile nodes BCEs that
that need to be removed. have a MN-ID with a realm that matches the NAI value in the received
MN-ID option and need to be removed.
When the mobile node is registered with multiple Home Network When the mobile node is registered with multiple Home Network
Prefixes for the same proxy care-of address, the local mobility Prefixes for the same proxy care-of address, the local mobility
anchor SHOULD include a HNP option for each registered HNP in the anchor SHOULD include a HNP option for each registered HNP in the
Binding Revocation Indication. Alternatively, it MAY include only Binding Revocation Indication. Alternatively, it MAY include only
the mobile node identifier, MN-ID, option to indicate to the mobile the mobile node identifier, MN-ID, option to indicate to the mobile
access gateway to remove all bindings of the specified mobile node access gateway to remove all bindings of the specified mobile node
NAI in the MN-ID option. NAI in the MN-ID option.
According to Proxy Mobile IPv6 specification [RFC5213], if the local According to Proxy Mobile IPv6 specification [RFC5213], if the local
skipping to change at page 26, line 41 skipping to change at page 28, line 34
9.1.2. Receiving Binding Revocation Acknowledgement 9.1.2. Receiving Binding Revocation Acknowledgement
When the local mobility anchor receives a packet carrying a valid When the local mobility anchor receives a packet carrying a valid
Binding Revocation Acknowledgement that was successfully processed as Binding Revocation Acknowledgement that was successfully processed as
in Section 7.2 and if the mobile node BCE is in the state of in Section 7.2 and if the mobile node BCE is in the state of
Revocation in progress, the local mobility anchor SHOULD examine the Revocation in progress, the local mobility anchor SHOULD examine the
Status field before clearing the mobile node related resources as Status field before clearing the mobile node related resources as
follows: follows:
o If the Status field indicates that the BRI was processed o If the Status field indicates that the BRI was processed
successfully, the local mobility anchor delete the MINDelayBRIs successfully, the local mobility anchor delete the current timer
timer and the mobile node proxy bindings and all associated and the mobile node proxy bindings and all associated resources.
resources.
o If the Status field indicates partial success value or MN binding o If the Status field indicates partial success value or MN binding
does not exist, the local mobility anchor SHOULD examine mobility does not exist, the local mobility anchor SHOULD examine mobility
options that are included in the Binding Revocation options that are included in the Binding Revocation
Acknowledgement, if any, before deleting the MINDelayBRIs timer Acknowledgement, if any, before deleting the current timer and the
and the mobile node associated proxy bindings and other related mobile node associated proxy bindings and other related resources.
resources. It is based on the local mobility anchor local policy It is based on the local mobility anchor local policy how to
how to handle the mobile node BCE(s) that the mobile access handle the mobile node BCE(s) that the mobile access gateway
gateway indicated it failed the revocation procedure, however, the indicated it failed the revocation procedure, however, the LMA MAY
LMA MAY log the event. log the event.
9.2. Binding Revocation Responder 9.2. Binding Revocation Responder
9.2.1. Receiving Binding Revocation Indication 9.2.1. Receiving Binding Revocation Indication
When the local mobility anchor receives a packet carrying a Binding When the local mobility anchor receives a packet carrying a Binding
Revocation Indication that was successfully processed as in Revocation Indication that was successfully processed as in
Section 7.2, the local mobility anchor SHOULD in addition process the Section 7.2, the local mobility anchor SHOULD in addition process the
message as follows: message as follows:
skipping to change at page 33, line 20 skipping to change at page 35, line 9
received Binding Revocation Acknowledgement as per the followings: received Binding Revocation Acknowledgement as per the followings:
o When the mobile access gateway receives a packet carrying a valid o When the mobile access gateway receives a packet carrying a valid
Binding Revocation Acknowledgement and the Global (G) and Proxy Binding Revocation Acknowledgement and the Global (G) and Proxy
Binding (P) bits are set and the mobile nodes BCEs are in the Binding (P) bits are set and the mobile nodes BCEs are in the
state of Revocation in Progress, the mobile access gateway SHOULD state of Revocation in Progress, the mobile access gateway SHOULD
examine the Status field as follows: examine the Status field as follows:
o If the Status field indicates that the Binding Revocation o If the Status field indicates that the Binding Revocation
Indication was processed successfully, the mobile access gateway Indication was processed successfully, the mobile access gateway
delete the MINDelayBRIs timer and the mobile nodes proxy bindings delete the current timer and the mobile nodes proxy bindings and
and all associated resources. 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 set to the same local mobility agent. The mobile access bit set to the same local mobility agent. The mobile access
gateway should raise an alarm or log an event to indicate this gateway should raise an alarm or log an event to indicate this
rejection. rejection.
11. Mobile Node Operation 11. Mobile Node Operation
skipping to change at page 35, line 43 skipping to change at page 37, line 33
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) Initial Minimum Delay Between BRI messages (InitMINDelayBRIs)
This variable specifies the delay time in seconds before the This variable specifies the initial delay timeout in seconds
revoking mobility entity retransmits a BRI message. The default before the revoking mobility entity retransmits a BRI message.
is 1 second but not less than 0.5 seconds. The default is 1 second but not less than 0.5 seconds.
Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)
This variable specifies the maximum delay timeout in seconds
before the revoking mobility entity retransmits a BRI message.
The default is 2 seconds.
13. IANA Considerations 13. IANA Considerations
This specification defines a new Binding Revocation Message using a This specification defines a new Binding Revocation Message using a
new Mobility Header Type <IANA-TBD>, as described in Section 6. The new Mobility Header Type <IANA-TBD>, as described in Section 6. The
new Mobility Header type value needs to be assigned from the same new Mobility Header type value needs to be assigned from the same
numbering space as allocated for the other Mobility Header types. numbering space as allocated for the other Mobility Header types.
This document also creates a new name space "Binding Revocation Type" This document also creates a new name space "Binding Revocation Type"
which indicates the type of the binding revocation message. The which indicates the type of the binding revocation message. The
current binding revocation message types are described in Section 6.1 current binding revocation message types are described in Section 6.1
and Section 6.2, and are the following: and Section 6.2, and are the following:
0 Reserved 0 Reserved
1 Binding Revocation Indication 1 Binding Revocation Indication
2 Binding Revocation Acknowledgement 2 Binding Revocation Acknowledgement
All other values are reserved All other values are reserved
Future values of the Binding Revocation Type can be allocated using Future values of the Binding Revocation Type can be allocated using
Standards Action or IESG Approval [RFC2434]. Standards Action or IESG Approval [RFC5226].
In addition, this document also creates a second new namespace for In addition, this document also creates a second new namespace for
the Revocation Trigger which indicates the reason behind sending the the Revocation Trigger which indicates the reason behind sending the
Binding Revocation Indication message. The current Revocation Binding Revocation Indication message. The current Revocation
Trigger values are described in Section 6.1, and are the following: Trigger values are described in Section 6.1, and are the following:
Reserved and Per-MN Revocation Trigger Values: Reserved and Per-MN Revocation Trigger Values:
0 Reserved 0 Reserved
1 Unspecified 1 Unspecified
2 Administrative Reason 2 Administrative Reason
skipping to change at page 36, line 48 skipping to change at page 38, line 42
7 Access Network Session(s) Termination 7 Access Network Session(s) Termination
8 Possible Out-of Sync BCE State 8 Possible Out-of Sync BCE State
250-255 Reserved For Testing Purposes only 250-255 Reserved For Testing Purposes only
All other values are Reserved All other values are Reserved
Global Revocation Trigger Values: Global Revocation Trigger Values:
128 Per-Peer Policy 128 Per-Peer Policy
129 Revoking Mobility Node Local Policy 129 Revoking Mobility Node Local Policy
Future values of the Revocation Trigger can be allocated using Future values of the Revocation Trigger can be allocated using
Standards Action or IESG Approval [RFC2434]. Standards Action or IESG Approval [RFC5226].
Furthermore, this document creates a third new name space "Status Furthermore, this document creates a third new name space "Status
Code" for the Status field in the Binding Revocation Acknowledgement Code" for the Status field in the Binding Revocation Acknowledgement
message. The current values are described in Section 6.2, and are message. The current values are described in Section 6.2, and are
the following: the following:
0 success 0 success
1 partial success 1 partial success
128 Binding Does NOT Exist 128 Binding Does NOT Exist
129 IPv4 Home Address Option Required 129 IPv4 Home Address Option Required
130 Global Revocation NOT Authorized 130 Global Revocation NOT Authorized
131 Revoked Mobile Nodes Identity Required 131 Revoked Mobile Nodes Identity Required
132 Revocation Failed - MN is Attached 132 Revocation Failed - MN is Attached
133 Revocation Trigger NOT Supported 133 Revocation Trigger NOT Supported
134 Revocation Function NOT Supported 134 Revocation Function NOT Supported
Future values of the Status field can be allocated using Standards Future values of the Status field can be allocated using Standards
Action or IESG Approval [RFC2434]. Action or IESG Approval [RFC5226].
All fields labeled "Reserved" are only to be assigned through All fields labeled "Reserved" are only to be assigned through
Standards Action or IESG Approval. Standards Action or IESG Approval.
14. Security Considerations 14. Security Considerations
The protocol described here uses the same security association The protocol described here uses the same security association
between the mobile node and the home agent or the mobile access between the mobile node and the home agent or the mobile access
gateway and the local mobility anchor that has been used to exchange gateway and the local mobility anchor that has been used to exchange
the corresponding MIPv6 or PMIPv6 Binding Update and Binding the corresponding MIPv6 or PMIPv6 Binding Update and Binding
skipping to change at page 38, line 10 skipping to change at page 40, line 10
draft and all colleagues who have supported the advancement of this draft and all colleagues who have supported the advancement of this
draft effort. draft effort.
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
October 1998. May 2008.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005. (MIPv6)", RFC 4283, November 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
skipping to change at page 39, line 32 skipping to change at page 41, line 32
Sri Gundavelli Sri Gundavelli
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
Kuntal Chowdhury Kuntal Chowdhury
Starent Networks Startent Networks
30 International Place 30 International Place
Tewksbury, MA 01876 Tewksbury, MA 01876
USA USA
Email: kchowdhury@starentnetworks.com Email: kchowdhury@starentnetworks.com
Parviz Yegani Parviz Yegani
Juniper Networks Juniper Networks
1194 North Mathilda Avenue 1194 North Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
 End of changes. 28 change blocks. 
119 lines changed or deleted 171 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/