draft-ietf-mext-binding-revocation-06.txt   draft-ietf-mext-binding-revocation-07.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: November 16, 2009 S. Gundavelli Expires: December 16, 2009 S. Gundavelli
Cisco Systems Cisco Systems
K. Chowdhury K. Chowdhury
Starent Networks Starent Networks
P. Yegani P. Yegani
Juniper Networks Juniper Networks
May 15, 2009 June 14, 2009
Binding Revocation for IPv6 Mobility Binding Revocation for IPv6 Mobility
draft-ietf-mext-binding-revocation-06.txt draft-ietf-mext-binding-revocation-07.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 16, 2009. This Internet-Draft will expire on December 16, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents 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 44 skipping to change at page 2, line 44
7. Binding Revocation Process Operation . . . . . . . . . . . . . 18 7. Binding Revocation Process Operation . . . . . . . . . . . . . 18
7.1. Sending Binding Revocation Messages . . . . . . . . . . . 18 7.1. Sending Binding Revocation Messages . . . . . . . . . . . 18
7.2. Receiving Binding Revocation Messages . . . . . . . . . . 19 7.2. Receiving Binding Revocation Messages . . . . . . . . . . 19
7.3. Retransmission of Binding Revocation Indication . . . . . 20 7.3. Retransmission of Binding Revocation Indication . . . . . 20
8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 20 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 20
8.1. Sending Binding Revocation Indication . . . . . . . . . . 20 8.1. Sending Binding Revocation Indication . . . . . . . . . . 20
8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 22 8.2. Receiving Binding Revocation Acknowledgement . . . . . . . 22
9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 22 9. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 22
9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 22 9.1. Binding Revocation Initiator . . . . . . . . . . . . . . . 22
9.1.1. Sending Binding Revocation Indication . . . . . . . . 22 9.1.1. Sending Binding Revocation Indication . . . . . . . . 22
9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 25 9.1.2. Receiving Binding Revocation Acknowledgement . . . . . 26
9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 25 9.2. Binding Revocation Responder . . . . . . . . . . . . . . . 27
9.2.1. Receiving Binding Revocation Indication . . . . . . . 26 9.2.1. Receiving Binding Revocation Indication . . . . . . . 27
9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 27 9.2.2. Sending Binding Revocation Acknowledgement . . . . . . 28
10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 28 10. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 29
10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 28 10.1. Binding Revocation Responder . . . . . . . . . . . . . . . 29
10.1.1. Receiving Binding Revocation Indication . . . . . . . 28 10.1.1. Receiving Binding Revocation Indication . . . . . . . 29
10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 30 10.1.2. Sending Binding Revocation Acknowledgement . . . . . . 31
10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 30 10.2. Binding Revocation Initiator . . . . . . . . . . . . . . . 31
10.2.1. Sending Binding Revocation Indication . . . . . . . . 30 10.2.1. Sending Binding Revocation Indication . . . . . . . . 32
10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 31 10.2.2. Receiving Binding Revocation Acknowledgement . . . . . 33
11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 32 11. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 33
11.1. Receiving Binding Revocation Indication . . . . . . . . . 32 11.1. Receiving Binding Revocation Indication . . . . . . . . . 33
11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 33 11.2. Sending Binding Revocation Acknowledgement . . . . . . . . 35
12. Protocol Configuration Variables . . . . . . . . . . . . . . . 34 12. Protocol Configuration Variables . . . . . . . . . . . . . . . 35
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
14. Security Considerations . . . . . . . . . . . . . . . . . . . 36 14. Security Considerations . . . . . . . . . . . . . . . . . . . 37
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.1. Normative References . . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . . 38
16.2. Informative References . . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
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 5, line 18 skipping to change at page 5, line 18
the protocol overview and applicable use cases. the protocol overview and applicable use cases.
3.1. Binding Revocation Protocol 3.1. Binding Revocation Protocol
In the case of Mobile IPv6, if the home network decides to terminate In the case of Mobile IPv6, if the home network decides to terminate
the service of the mobile node, the home agent sends a Binding the service of the mobile node, the home agent sends a Binding
Revocation Indication (BRI) message to the mobile node. The home Revocation Indication (BRI) message to the mobile node. The home
agent includes the home address (HoA) of the mobile node in the Type agent includes the home address (HoA) of the mobile node in the Type
2 routing header as specified in [RFC3775] to indicate the impacted 2 routing header as specified in [RFC3775] to indicate the impacted
mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6) mobile node binding. In the case of Dual Stack Mobile IPv6 (DSMIPv6)
[ID-DSMIP6], the home agent may include the IPv4 Home Address option [RFC5555], the home agent may include the IPv4 Home Address option
with the mobile node assigned home IPv4 address. Additionally, if with the mobile node assigned home IPv4 address. Additionally, if
the mobile node registered multiple care-of addresses [ID-MCoA], the the mobile node registered multiple care-of addresses [ID-MCoA], the
home agent includes the Binding Identifier (BID) option(s) in the home agent includes the Binding Identifier (BID) option(s) in the
Binding Revocation Indication message to identify which binding is Binding Revocation Indication message to identify which binding is
being revoked. When the mobile node receives a Binding Revocation being revoked. When the mobile node receives a Binding Revocation
Indication message with its HoA included in the Type 2 routing header Indication message with its HoA included in the Type 2 routing header
and the Acknowledge (A) bit is set, the mobile node responds by and the Acknowledge (A) bit is set, the mobile node responds by
sending a Binding Revocation Acknowledgement (BRA) message. sending a Binding Revocation Acknowledgement (BRA) message.
Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation Similarly, in the case of Proxy Mobile IPv6 [RFC5213], the revocation
skipping to change at page 15, line 38 skipping to change at page 15, line 38
when the (P) bit is set. Additionally, if the (G) bit is set by when the (P) bit is set. Additionally, if the (G) bit is set by
the mobile access gateway, this option carries the MAG identity. the mobile access gateway, this option carries the MAG identity.
o Binding Identifier mobility option [ID-MCoA]. This option is o Binding Identifier mobility option [ID-MCoA]. This option is
mandatory if the sending mobility entity requests to terminate one mandatory if the sending mobility entity requests to terminate one
binding of a multi care-of addresses bindings for the same mobile binding of a multi care-of addresses bindings for the same mobile
node. The sending mobility entity may include more than one of node. The sending mobility entity may include more than one of
the BID mobility options. the BID mobility options.
o IPv4 Home Address option which contains the mobile node home IPv4 o IPv4 Home Address option which contains the mobile node home IPv4
address [ID-DSMIP6]. This option is included only when the IPv4 address [RFC5555]. This option is included only when the IPv4 HoA
HoA Binding only (V) bit is set. Binding only (V) bit is set.
o Alternate Care-of Address mobility option [RFC3775]. This option o Alternate Care-of Address mobility option [RFC3775]. This option
MAY be included to indicate the Care-of Address of the mobile MAY be included to indicate the Care-of Address of the mobile
node's binding that is being revoked. In the case when the Global node's binding that is being revoked. In the case when the Global
(G) bit set, this option identifies all the mobility bindings that (G) bit set, this option identifies all the mobility bindings that
share the same care-of address. Additionally, if the Global (G) share the same care-of address. Additionally, if the Global (G)
bit set, more than one Alternate Care-of Address mobility options bit set, more than one Alternate Care-of Address mobility options
MAY be present in the Binding Revocation Indication message. MAY be present in the Binding Revocation Indication message.
If no options are present in this message, 4 octets of padding are If no options are present in this message, 4 octets of padding are
skipping to change at page 24, line 44 skipping to change at page 24, line 44
that need to be removed. that 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
mobility anchor receives a Proxy Binding Update message from a new
mobile access gateway for extending the binding lifetime of the only
BCE of this mobile node with the Handoff Indicator value is set to
"Inter-MAG Handover - Unknown", the local mobility anchor waits a
period of MaxDelayBeforeNewBCEAssign to receive a de-registration
message from the previous mobile access gateway before updating the
mobile node's BCE with the new point of attachment. If a de-
registration message is not received,, the local mobility anchor
considers the received Proxy Binding Update message as a request for
a new BCE and if processed successfully, the local mobility anchor
assigns a different HNP for the new BCE.
This document updates the local mobility anchor's behavior in this
case. If the local mobility anchor supports the binding revocation
mechanism as described in this document, it SHOULD proactively send a
Binding Revocation Indication message to the previous mobile access
gateway instead of waiting for a de-registration from the previous
mobile access gateway. In the Binding Revocation Indication message,
the (A) bit MUST be set and the Revocation Trigger MUST be set to
"Inter-MAG Handover - Unknown".
If the local mobility anchor sent a Binding Revocation Indication
message with the Revocation Trigger field set to "Inter-MAG Handover
- Unknown" and while waiting for a Binding Revocation Acknowledgement
response, the following are possible conditions that the local
mobility anchor MUST handle as specified below:
o If the local mobility anchor receives a successful Binding
Revocation Acknowledgement message or a de-registration message
from the previous mobile access gateway, the local mobility anchor
MUST update the mobile node BCE in a similar way as if it received
a de-registration message as described in [RFC5213].
o If the local mobility anchor receives a Binding Revocation
Acknowledgement message with the status field set to "Revocation
Failed - MN is Attached", the local mobility anchor SHOULD update
the mobile node BCE in a similar way as if it did NOT receive a
de-registration before the MaxDelayBeforeNewBCEAssign timer
expires by creating a new BCE as described in [RFC5213].
o If the local mobility anchor did not receive a Binding Revocation
Acknowledgement message nor a de-registration Proxy Binding Update
from the previous mobile access gateway after it exhausted all of
the Binding Revocation Indication message retransmissions as
described in Section 7.3, the local mobility anchor SHOULD update
the mobile node's BCE in a similar way as if it did NOT receive a
de-registration before the MaxDelayBeforeNewBCEAssign timer
expires by creating a new BCE as described in [RFC5213]. Note
that the local mobility anchor SHOULD use the recommended number
of retransmissions for the Binding Revocation Indication message
as described in Section 12 to avoid delaying the creation of a new
binding cache entry for too long, if the mobile node is actually
attaching to the new MAG with a different interface.
When the mobile node is registered with an IPv4 proxy home address in 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 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 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 revoke the mobile node IPv4 proxy HoA binding to the current mobile
node proxy CoA while maintaining the mobile node binding of the HNP node proxy CoA while maintaining the mobile node binding of the HNP
to its current pCoA as part of the mobile node BCE. In this case, if to its current pCoA as part of the mobile node BCE. In this case, if
the local mobility anchor decides to revoke the mobile node IPv4 the local mobility anchor decides to revoke the mobile node IPv4
proxy HoA ONLY, it MUST send a Binding Revocation Indication message proxy HoA ONLY, it MUST send a Binding Revocation Indication message
following the procedure in Section 7.1 and the following rules: following the procedure in Section 7.1 and the following rules:
skipping to change at page 37, line 25 skipping to change at page 38, line 34
[ID-PMIP6-IPv4] [ID-PMIP6-IPv4]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-10 Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-10
(work in progress), March 2009. (work in progress), March 2009.
[ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration", "Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-12 (work in progress), draft-ietf-monami6-multiplecoa-12 (work in progress),
March 2009. March 2009.
[ID-DSMIP6] [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009.
Routers", draft-ietf-mext-nemo-v4traversal-09 (work in
progress), February 2009.
16.2. Informative References 16.2. Informative References
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003. Mobile IPv4", RFC 3543, August 2003.
Authors' Addresses Authors' Addresses
 End of changes. 9 change blocks. 
33 lines changed or deleted 86 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/