Internet DRAFT - draft-petander-mip6-mbb
draft-petander-mip6-mbb
Mip6 Working Group Henrik Petander
Eranga Perera
Internet Draft National ICT Australia
Expires: April 2006 October 16, 2005
Improved Binding Management for Make Before Break Handoffs in Mobile
IPv6
draft-petander-mip6-mbb-00.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.
This document may only be posted in an Internet-Draft.
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 April 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Mobile IPv6 binding management has been designed for break-before-
make handoffs, which can be performed by hosts equipped with a single
Petander Expires April 16, 2006 [Page 1]
Internet-Draft draft-petander-mip6-mbb-00.txt October 2005
interface. However, a Mobile Node may be equipped with multiple
interfaces, allowing it to perform Make-Before-Break handoffs by
connecting simultaneously to two overlapping access networks during
the handoff. In theory these handoffs can be lossless, provided that
there is sufficient overlap between the two networks. However, unless
Mobile IPv6 bindings are managed carefully Mobile Node and
Correspondent Node will have inconsistent binding state during the
handoff, which will lead to packet loss. In this draft we propose
changes to binding management for lossless make-before-break
handoffs. The proposed changes do not affect the interoperability
with Mobile IPv6 nodes not implementing these changes.
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 RFC-2119 [1].
We refer to Home Agent (HA) and Correspondent Node (CN) as
Correspondent Node for brevity, and distinguish between them only
when there is a difference in their or Mobile Node's behavior.
1. Introduction
In a Break-Before-Make (BBM) handoff, Mobile Node (MN) loses
connectivity with its old access network before connecting to a new
one. In a Make-Before-Break (MBB) handoff MN is still connected to
its old Access Router while performing a handoff using a new one. MBB
handoffs can in theory be completely lossless, since MN can receive
data to its Care-of Address (CoA) on the old access network while
registering a new CoA with its HA and CNs via the new access network.
Normally, only MNs equipped with multiple interfaces can perform MBB
handoffs. For example, inter access technology handoffs can often be
performed as MBB handoffs. A MN may also be equipped with multiple
interfaces of the same type and can use them for lossless intra
access technology handoffs as proposed in [3].
In this draft we propose an extension to Mobile IPv6 [2] signaling
and binding management to enhance performance of MBB handoffs. We
first describe the problem, and then look at possible solutions and
finally we propose changes to Mobile IPv6 binding update list and
binding cache management.
2. Problem of Inconsistent Binding State between MN and CN
In MBB handoffs MN is able to receive and send data using its old CoA
for the duration of the handoff to the new CoA. Completion of the
Petander Expires April 16, 2006 [Page 2]
Internet-Draft draft-petander-mip6-mbb-00.txt October 2005
handoff in Mobile IPv6 means either sending a Binding Update (BU) or
receiving a Binding Acknowledgement (BA). In order for MN to be able
to send and receive packets during the handoff, MN and CN need to
have a synchronous state of the binding between the home address and
the CoA of MN. The problem is that MN cannot know with certainty when
the binding cache entry of CN is updated to the new CoA, only that it
happens between sending of BU and receiving of BA.
If MN changes its binding when sending BU (instead of waiting for
BA), it will drop all packets CN sends using the old CoA, i.e.
packets CN has sent before it received BU: MN compares the CoA in its
binding update list with (new CoA) with the old CoA used as
destination address in IPv6 header, and drops the packets due to the
mismatch. This is not necessarily the case for route optimized MN -
CN communication due to the more relaxed checks, but will cause MN to
drop all packets tunneled by HA due to the more strict checks on the
tunnel header. MN can avoid this by changing its binding update list
entry for CN to use new CoA only when receiving BA. However, during
the time period between CN receiving BU and MN receiving BA, MN is
likely to send packets to CN using the old CoA. CN will drop these
packets due to the mismatch with the CoA in its binding cache and the
one in the packets.
As long as a MN and a CN use unmodified Mobile IPv6 signaling and
binding management, it is impossible for them to have a consistent
state for the home address to CoA binding.
3. Options for ensuring consistency of incoming and outgoing states for
Binding Update List and Binding Cache
With unmodified Mobile IPv6 signaling there exist two possible
solutions for ensuring consistent state of bindings in CN and MN.
Both solutions require that either MN or CN accepts incoming packets
with the old CoA for a certain period after updating its binding(s)
to use the new CoA.
MN can update its binding update list entry for outgoing packets to
include the new CoA immediately after sending BU. This will ensure
that if packets arrive in the correct order at HA, i.e. after the BU,
they will match the binding state and be processed correctly. To
enable MN to receive incoming packets which CN sends to old CoA
before it receives BU, MN also needs to retain the binding update
list state for old CoA for receiving tunneled and route optimized
packets sent by CN. MN needs to retain the old state until it
Petander Expires April 16, 2006 [Page 3]
Internet-Draft draft-petander-mip6-mbb-00.txt October 2005
receives BA or possibly for longer to handle packets arriving out of
order.
This approach has the potential drawback of outgoing packets sent by
MN being lost, if HA or CN does not receive or accept the BU
immediately. An example of non-immediate binding cache update in HA
is the case of MN moving from its home network to a foreign network
and HA performing proxy DAD before updating its binding cache.
However, MN knows when it is registering for the first time, so it
can avoid this problem. To avoid loss of packets due to BUs lost in
transit, MN can send two BUs through both the old and new interfaces.
A second option is to retain the old binding cache entry in CN with
old CoA of MN for a short period of time after receiving a BU from MN
including a new CoA and sending a BA. This allows MN to wait for a BA
from CN before it starts using the new CoA for outgoing
communications. In this case MN would send its packets via its old
access router using the old CoA for the duration of a RTT between MN
and HA (and any other delays, such as proxy DAD). To ensure
consistent state for the new CoA MN needs to request for a BA, so
that it knows for sure when CN has processed and accepted the BU.
The latter option is more reliable, but also results in a slower
handoff for outgoing packets. In some cases the handoff may take
longer than the simultaneous connectivity to the old and new network
and MN would be better of by using the new CoA at the new access
router as soon as possible. If CN accepts incoming packets with old
CoA, MN can choose between using its old and new CoA for outgoing
packets for the period of time between sending BU and receiving BA
depending on the situation.
4. Changes to use and management of Binding Update List
MN MAY keep its state for the Binding Update Entry with its old CoA
after sending a Binding Update containing its new CoA to CN. MN
SHOULD keep this entry until it can be safely deleted. In the case of
BU to HA MN SHOULD remove its OLD_BUL_STATE_LIFETIME seconds after
receiving a positive BA from HA. In the case of BU to CN, MN SHOULD
remove it OLD_BUL_STATE_LIFETIME seconds after receiving a positive
BA from CN or if MN did not request a BA from CN
OLD_BUL_STATE_LIFETIME after sending the BU.
MN SHOULD accept packets from CN using the old CoA during the
lifetime of the entry. MN MAY also send packets to CN using the old
CoA until it gets a BA from CN indicating success of BU. MN SHOULD
set the acknowledgment flag in BU, if MN uses the old CoA to send
packets to CN after sending BU. If old CoA can be used for sending
Petander Expires April 16, 2006 [Page 4]
Internet-Draft draft-petander-mip6-mbb-00.txt October 2005
packets between BU and BA, this use MUST be configurable, so that the
default is to use the new CoA.
5. Changes to use and management of Binding Cache
CN MAY keep its state for Binding Cache Entry with the old CoA of MN
after accepting a Binding Update from MN for a period of
OLD_BC_STATE_LIFETIME. During this time CN SHOULD accept packets from
MN with the old CoA. CN MUST not use the old CoA for sending packets
to MN.
6. Security Considerations
An attacker on the previous link of MN could inject packets with the
old CoA to CN or HA during the lifetime of the receiving state for
old CoA, if MN disconnects from the old link before binding cache or
binding update list entries for the old CoA are deleted. However, the
short lifetime of the receiving state for old CoA limits the scope of
any vulnerability created by the dual receiving state in MN and CN.
7. Protocol Constants
OLD_BUL_STATE_LIFETIME - 2s
OLD_BC_STATE_LIFETIME - 1s
A lifetime of 1s for old BC entries guarantees that the entries do
not accumulate, since 1s is the minimum BU interval.
Petander Expires April 16, 2006 [Page 5]
Internet-Draft draft-petander-mip6-mbb-00.txt October 2005
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and Arkko J., "Mobility Support in
IPv6", RFC 3775, June 2004.
9. Informative References
[3] Petander H., Perera E., Seneviratne A., "Multiple Interface
Handoffs: A Practical Method for Access Technology Independent
Make-Before-Break Handoffs", NICTA Technical Report, July 2005,
http://nicta.com.au/uploads/documents/PA005092_NICTA1.pdf
Author's Address
Henrik Petander
National ICT Australia
Australian Technology Park
Bay 15 Locomotive Workshop,
Eveleigh NSW 1430
Australia
Email: henrik.petander@nicta.com.au
Eranga Perera
National ICT Australia
Australian Technology Park
Bay 15 Locomotive Workshop,
Eveleigh NSW 1430
Australia
Email: eranga.perera@nicta.com.au
Petander Expires April 16, 2006 [Page 6]
Internet-Draft draft-petander-mip6-mbb-00.txt October 2005
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 (2005).
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.
Acknowledgments
Funding for the RFC Editor function is currently provided by the
Internet Society.
Petander Expires April 16, 2006 [Page 7]
