Internet DRAFT - draft-chen-mipshop-fast-handovers-prep-binding
draft-chen-mipshop-fast-handovers-prep-binding
MIPSHOP Working Group HF. CHEN
Jian. Zhang
Internet Draft HUAWEI
Expires: Oct 18, 2006 April 17, 2006
Prep-Binding of Fast Handovers for Mobile IPv6
draft-chen-mipshop-fast-handovers-prep-binding-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of 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 Oct 18, 2006.
chen Expires Oct 18, 2006 [Page 1]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
Fast Handovers have been specified in Fast Handovers for Mobile IPv6
defined in RFC4068. This document discussed the issues which happen
after MN move to NAR and before finishing bind update.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................3
3. Prep-Binding Update.........................................4
3.1. Problem statement.......................................4
3.2. Solution of Prep-Binding Update.........................5
3.2.1. Mobile Node Operation..............................5
3.2.2. Correspondent Node Operation.......................6
3.2.3. Process of Prep-Binding Update.....................8
3.3. Issues of Prep-Binding Update...........................9
4. Security Considerations.....................................10
5. IANA Considerations........................................10
6. Conclusions................................................10
7. Acknowledgments............................................10
8. References.................................................11
8.1. Normative References...................................11
8.2. Informative References.................................11
Author's Addresses............................................11
Intellectual Property Statement................................12
Disclaimer of Validity........................................12
Copyright Statement...........................................12
Acknowledgment................................................12
1. Introduction
The Fast Handovers for Mobile IPv6 document [RFC4068] defines the
Fast Handovers mechanisms between PAR and NAR.
After MN move to NAR from PAR and before MN finish binding update,
MN has to use PCoA as source IP address for communication with CN by
reverse tunnel. This document discusses a solution which support the
binding update when MN still in PAR network (Prep-Binding). Prep-
Binding should send CNoA to CN. This solution support NCoA for
source IP address at that time without tunnel.
chen Expires October 17, 2006 [Page 2]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
The following documents have been reviewed while drafting this
document:
o Fast Handovers for Mobile IPv6[RFC4068]
o Mobility Support in IPv6 [RFC3775]
2. Terminology
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 RFC 2119 [1]. The use
of the term, "silently ignore" is not defined in RFC 2119. However,
the term is used in this document and can be similarly construed.
This document borrows all of the terminology from RFC4068. The
following terminology and abbreviations are used in this document.
Prep-Binding Update(PBU)
Special BU message which is sent by MN when MN generated
NCoA local in PAR
Prep-Binding Acknowledgement(PBA)
The Prep-Binding Acknowledgement is used to acknowledge
receipt of a Prep-Binding Update
Transitional Period of MN(TPoMN)
The period of MN after MN moves to NAR before MN finishes
Binding Update
chen Expires October 17, 2006 [Page 3]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
Prep-Entry(PEntry)
A special entry in binding cache of CN created by
PBU(defined in section 3.2.)
3. Prep-Binding Update
3.1. Problem statement
v +------------+
+-+ | Previous | <
| | ---------- | Access | ------ > ----\
+-+ | Router | < \
MN | (PAR) | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Access | ------ > ----/
+-+ | Router | <
MN | (NAR) |
+------------+
Figure 1: Reference Scenario for Handover
The figure 1 is borrowed from RFC4068
In section 3.1 of RFC4068, it described the transitional action of MN
in TPoMN. MN could receive packets from NAR while PAR SHOULD forward
packets in the tunnel to NAR. In the opposite direction, MN SHOULD
transmit packets to PAR by reverse tunnel until it completes the
Binding Update.
There are two problems with this solution. First is that one more
IPv6 header need to be added in each packet from MN to CN. It should
reduce the usable bandwidth of the network. Second is that the PAR
chen Expires October 17, 2006 [Page 4]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
and the MN MUST support reverse tunnel. It will farther reduce the
performance of transmission while a great many tunnels are generated.
This document discuss an alternative solution in section 3.2
3.2. Solution of Prep-Binding Update
3.2.1. Mobile Node Operation
MN sends PBU to CN after MN receives PrRtAdv from PAR and a NCoA
generated. The CoA carried in PBU message is NCoA. If MN received PBA
from CN, MN sends packets to CN using NCoA as source IP address in
TPoMN. PAR didn't need a reverse tunnel which is required by the
Fmipv6.
Prep-Binding Update(PBU)
It should use 1 reserved bit of BU message which defined in section
6.1.7 RFC3775.
+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
chen Expires October 17, 2006 [Page 5]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+
Acknowledge (A)
The Acknowledge (A) bit MUST be set in the PBU message by MN to
request a Prep-Binding Acknowledgement to be returned by CN.
Prep-Binding(P)
The Prep-Binding Update(P) bit is set by MN to request CN to
create a new special entry in their Binding Cache. It means this
binding is a temporary Binding Update. The entry which created by
this kind of Binding Update works in TPoMN only. Because this entry
works before formal Binding Update, the Prep-Lifetime which defined
in section 3.2.2 in this packet should not be a large number. Setting
3 or 4 for Prep-Lifetime is desirable to increase security.
3.2.2. Correspondent Node Operation
CN should setup a Prep-Binding Entry after CN received PBU and get
NCoA.
Conceptual Data Structures in CN
o The home address of the mobile node.
o The care-of address for the mobile node.
o A lifetime value
o A flag indicating whether this Binding Cache entry is a home
registration entry (applicable only on nodes which support home agent
functionality).
o The maximum value of the Sequence Number field received in
previous Binding Updates for this home address.
o Usage information for this Binding Cache entry.
o A perp-lifetime of Prep-binding Update which
0 A formal Binding Cache Entry which process as same as
defined in [RFC3775]
chen Expires October 17, 2006 [Page 6]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
>0: A PEntry should work in TPoMN. The number of Perp-
Lifetime means that lifetime of this entry after MN sent packet with
NCoA as source IP address in TPoMN. The lifetime of this entry
started to account when CN receive the first packet which the source
IP address is the NCoA in this entry. After start to account, the
lifetime of entry is the time of the lifetime record
CN send a Prep-Binding Acknowledgement with status is 2 to
acknowledge receipt of a PBU after setup PEnrty.
Prep-Binding Acknowledgement(PBA)
Two new status should be modified in BA which defined in section
6.1.8 RFC3775
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Status
0 Binding Update accepted
1 Accepted but prefix discovery necessary
2 Prep-Binding Update accepted
140 Prep-Binding Update refused
... the other status defined same as RFC3775
chen Expires October 17, 2006 [Page 7]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
Lifetime: The Lifetime in PBU is the perp-lifetime in PEntry. The lifetime
of this entry started to count when CN receive the first packet whose
source IP address is the NCoA.
3.2.3. Process of Prep-Binding Update
CN/HA MN PAR NAR
| |------RtSolPr------>| |
| |<-----PrRtAdv-------| |
1 | <------PBU-------| | |
2 | -------PBA------>| | |
| |------FBU---------->|------HI------>|
| | |<-----HAck-----|
| | <--FBack---|--FBack---> |
| disconnect forward |
| | packets==========>|
| connect | |
| |--------- FNA --------------------->|
| forward packets | |
3 PEentry<=============by NCoA | |
| |<====================== deliver packets
|<-process of BU-> | | |
| | | |
formal forward packets | |
chen Expires October 17, 2006 [Page 8]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
entry<==============by NCoA | |
| | | |
figure 3:Prep-Binding Fast Handover
The figure 3 describes the process of Prep-Binding Fast Handover. The
lines marked as 1, 2 and 3 are key point of the process.
o Step 1, MN sends PBU to CN after MN received PrRtAdv
o Step 2, CN creates a special entry in Binding Cache and
feedbacks PBA to MN.
o Step 3, when MN moves to NAR. MN sends packet containing NCoA
as source IP address. CN processes packet by PEntry.
3.3. Issues of Prep-Binding Update
Several issues of Prep-Binding Update should be discussed about this
document.
1. Process's integrality of Prep-Binding Update
The DAD of home address and the Return Routability Procedure are not
discussed in this document. But the draft-zhang-mipshop-proactive-
cot-00.txt has discussed the issues of proactive Care-of Address Test
2. Assigned Addressing in RFC4068
The RFC4068 define that the MN MUST use the assigned address upon
attaching to NAR If there is an assigned NCoA in the FBack message.
When should MN send PBU and receive PBA should be discussed. PEntry
in Binding Cache of CN should be wrong if PBU and PBA are sent before
Hack message and assigned addressing including in Hack.
3. Home Agent Operation
Does HA create PEntry? It is an issue.
chen Expires October 17, 2006 [Page 9]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
4. Security Considerations
Prep-Binding Update should increase discussion of security. It could
be deceived attack if Prep-Binding Update has no mechanism of the
authentication and the security.
5. IANA Considerations
There are no IANA considerations defined in this document.
6. Conclusions
This document described a kind of technique that MN could use NCoA
before Binding Update when MN moved to NAR's network. The NAR and PAR
are the router in access layer of network. The router's ability of
transmitting in access layer is low usually. Tunnel between MN and
PAR should reduce the ability of transmitting further. This document
suggests Prep-Binding Update to reduce the load of PAR.
7. Acknowledgments
chen Expires October 17, 2006 [Page 10]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
8. References
8.1. Normative References
[RFC4068] R. Koodli, Ed. "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[RFC3775] D. Johnson. and C. Perkins and J. Arkko, " Mobility
Support in IPv6", RFC 3755, June 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
8.2. Informative References
[Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proc. Infocom 1999 pp.
1573-1583.
Author's Addresses
Hongfei Chen
HUAWEI
Hua Wei Bld.,No.3 Xinxi Rd.,
Shang-Di Information Industry Base
Hai-Dian District
Beijing P.R.China
Phone: +86 010 82882540
Email: chenhongfei@huawei.com
Jian Zhang
HUAWEI
Hua Wei Bld.,No.3 Xinxi Rd.,
Shang-Di Information Industry Base
Hai-Dian District
Beijing P.R.China
Phone: +86 010 82882233
Email: hwzhj@huawei.com
chen Expires October 17, 2006 [Page 11]
Internet-Draft Perp-Binding of Fast Handovers for Mobile IPv6 April
2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
chen Expires October 17, 2006 [Page 12]
