One document matched: draft-cui-mext-cn-binding-revocation-00.txt
Mext Working Group X. Cui (Ed.)
Internet Draft Huawei
Intended status: Standards Track A. Makela
Expires: May 2010 TKK
November 9, 2009
Binding Revocation from correspondent node in Route Optimization Mode
draft-cui-mext-cn-binding-revocation-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 8 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Cui Expires May 8, 2010 [Page 1]
Internet-Draft CN Binding Revocation November 2009
Abstract
This document specifies an extension to Binding Revocation mechanism;
the correspondent node may also initiate the binding revocation in
Route Optimization mode. This extension provides a method to change
the Route Optimization mode to the Bidirectional Tunneling mode.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Cui Expires May 8, 2010 [Page 2]
Internet-Draft CN Binding Revocation November 2009
Table of Contents
1. Introduction..................................................4
2. Terminology...................................................4
3. Protocol and Use Case Overview................................5
4. Correspondent Node Operation..................................6
5. Mobile Node Operation.........................................7
6. Messages and Options..........................................8
7. Security Considerations.......................................8
8. IANA Considerations...........................................8
9. Acknowledgments...............................................8
10. References...................................................8
10.1. Normative References....................................8
10.2. Informative References..................................9
Author's Addresses...............................................9
Cui Expires May 8, 2010 [Page 3]
Internet-Draft CN Binding Revocation November 2009
1. Introduction
Mobility Support in IPv6 [RFC3775] specifies two possible modes for
communications between the Mobile Node (MN) and a Correspondent Node
(CN), Bidirectional Tunneling mode and Route Optimization (RO) mode.
As specified in [RFC3775], Route Optimization mode "requires the
mobile node to register its current binding at the correspondent
node." When the mobile node want to transmit a packet, it also need
check whether there is a Binding Update List entry for the
destination of the packet, as specified in section 11.3.1 of
[RFC3775]. If the mobile node confirms that the correspondent node
has a suitable Binding Cache entry, the mobile node may send the
packet to the correspondent node in route optimization mode.
For the mobile node, which mode to be used depends on whether the
correspondent node Binding Update List entry exists or not.
[mext-binding-revocation] specifies a binding revocation mechanism,
which permit HA/LMA to send Binding Revocation Indication to the
MN/MAG, to terminate the MN's mobility session and release the
associated resources. The binding revocation mechanism specified in
[mext-binding-revocation] is only applied for the binding in Home
Agent or Local Mobility Anchor, but can not be applied for the
binding in correspondent node.
In some cases, the correspondent node also needs the capability to
revoke the correspondent binding from the mobile node during a route
optimized session.
This document is used to introduce the mechanism used by
correspondent node to terminate the correspondent node binding in the
MN's Binding Update List.
2. Terminology
All the general mobility related terminology and abbreviations are to
be interpreted as defined in Mobile IPv6 [RFC3775] and [mext-binding-
revocation].
Cui Expires May 8, 2010 [Page 4]
Internet-Draft CN Binding Revocation November 2009
3. Protocol and Use Case Overview
The overview of correspondent node binding revocation procedure is as
below:
MN HA CN
| | |
| HoTI | |
(a) |--------------------->| HoTI |
(b) | |--------------------->|
| | HoT |
(c) | HoT |<---------------------|
(d) |<---------------------| |
| |
| CoTI |
(e) |-------------------------------------------->|
| CoT |
(f) |<--------------------------------------------|
| |
| Binding Update |
(g) |-------------------------------------------->|
| Binding Ack |
(h) |<--------------------------------------------|
| |
| Binding Revocation Indication |
(i) |<--------------------------------------------|
| Binding Revocation Acknowledgement |
(j) |-------------------------------------------->|
| |
Figure 1 CN binding and revocation.
The detailed descriptions are as follows:
(a)~(f) Normal Return Routability procedure as specified in
[RFC3775].
(g)~(h) Normal Route Optimization binding registration as specified
in [RFC3775].
(i) The correspondent node sends the Binding Revocation Indication
packet to the mobile node, including the Binding
Authorization Data Option in the message.
Cui Expires May 8, 2010 [Page 5]
Internet-Draft CN Binding Revocation November 2009
(j) The mobile node deletes the correspondent node binding, releases
related resource and replies the Binding Revocation
Acknowledgement message to the correspondent node. After this
step, the Route Optimization mode is released and the
Bidirectional Tunneling mode is applied.
4. Correspondent Node Operation
To terminate the correspondent node binding in the MN's Binding
Update List, the correspondent node sends a packet to the mobile node
containing a Binding Revocation Indication as specified in section 7
of [mext-binding-revocation], with the exception as following:
o The source address of the packet MUST be set as the IP address of
the correspondent node, if the correspondent node is a mobile node
the home address of the node MUST be taken as the IP address.
o The Binding Authorization Data option, which is specified in
section 6.2.7 of [RFC3775], MUST be included in the Binding
Revocation Indication packet. Since the communication between the
mobile node and the correspondent node is not protected by
security association, the sender of the BRI MUST provide the
Authorization option. The Binding Management Key specified in
[RFC3775], the calculation of the Kbm specified in the section
5.2.5 of [RFC3775] and the calculation of the Authenticator
specified in the section 6.2.7 of [RFC3775] are reused in this
document.
o After the Binding Revocation Indication packet has been sent, the
correspondent MUST set a flag in the correspondent Binding Cache
entry to indicate the "Revocation Pending" state and stop
transmitting any outgoing packets (except retransmitted BRI)
destined directly for the mobile node.
o In the "Revocation Pending" state the correspondent node MUST
accept incoming route optimized packets until the Binding Cache
entry is freed.
o The correspondent node SHOULD maintain the "Revocation Pending"
state until Binding Revocation Acknowledgement has been received
or the maximum number of retransmissions have been conducted as
specified in section 6.3 of [mext-binding-revocation].
Cui Expires May 8, 2010 [Page 6]
Internet-Draft CN Binding Revocation November 2009
o The correspondent node MAY free all resources associated with this
mobile node binding in the cases of receiving the Binding
Revocation Acknowledgement or finishing the retransmission
procedure.
o If the correspondent node receives packet containing Home Address
option after it has freed the Binding Cache entry and related
resource, whether to accept the packet or not depends on the
implementation of the correspondent node. This is out of the scope
of this document.
5. Mobile Node Operation
Upon receiving a packet carrying a Binding Revocation Indication, the
mobile node MUST validate the packet according to Section 6.2 of
[mext-binding-revocation], with the addition of following tests:
o The mobile node MUST verify that the IP address in the Type 2
routing header is its Home Address. If the test fails, the mobile
node SHOULD silently discard the received Binding Revocation
Indication message.
o The mobile node MUST verify the source address of the received
Binding Revocation Indication packet. If the mobile node Binding
Update List contains an entry for the IP address, the mobile node
MUST check the Binding Authorization Data option contained in this
packet. If the Authenticator is valid and other tests are
verified, the mobile node MUST accept this Binding Revocation
Indication. Otherwise the mobile node SHOULD silently discard the
received Binding Revocation Indication message. The Binding
Management Key specified in [RFC3775], the calculation of the Kbm
specified in the section 5.2.5 of [RFC3775] and the calculation of
the Authenticator specified in the section 6.2.7 of [RFC3775] are
reused in this document.
o If the mobile node accepts this Binding Revocation Indication, the
mobile node MUST send a successful Binding Revocation
Acknowledgement to the correspondent node. Otherwise the mobile
node MUST send a rejected Binding Revocation Acknowledgement.
o After the mobile node has accepted the Binding Revocation
Indication message, the mobile node MAY free the resources related
to the correspondent node Binding Update List entry. The mobile
node MUST stop transmitting any outgoing packets destined directly
for the correspondent node after acknowledgement has been sent.
Cui Expires May 8, 2010 [Page 7]
Internet-Draft CN Binding Revocation November 2009
o If the mobile node receives packet containing type 2 routing
header after it has freed the correspondent node binding, whether
to accept the packet or not depends on the implementation of the
mobile node. This is out of the scope of this document. [[ Note:
This case is also possible in basic MIP6 network. The mobile node
maybe receives packet containing type 2 routing header before the
Binding Acknowledgement message, because the BA message and route
optimized packets are transported disorderly in the IP network.]]
6. Messages and Options
TBD.
7. Security Considerations
TBD.
8. IANA Considerations
This document has no actions for IANA.
9. Acknowledgments
The authors would like to thank Mext Working Group for the review,
comment and discussion.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Cui Expires May 8, 2010 [Page 8]
Internet-Draft CN Binding Revocation November 2009
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[mext-binding-revocation] Ahmad, M., Mohamed, K., Sri, G., Kuntal, C.
and Parviz, Y., "Binding Revocation for IPv6 Mobility",
October 2009.
10.2. Informative References
Author's Addresses
Xiangsong Cui
Huawei Technologies
KuiKe Bld., No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District, Beijing, P.R. China, 100085
Email: Xiangsong.Cui@huawei.com
Antti Makela
Helsinki University of Technology
P.O. BOX 3000
FIN-02105 TKK
FINLAND
Phone: +358 9 451 5590
Email: antti.makela@tkk.fi
Cui Expires May 8, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 08:09:01 |