Technical Summary
This document specifies a protocol to improve handover latency
due to Mobile IPv6 procedures. During handover, there is a period
during which the Mobile Node is unable to send or receive packets
because of link switching delay and IP protocol operations. This
"handover latency" resulting from standard Mobile IPv6 procedures,
namely movement detection, new Care-of Address configuration, and
Binding Update, is often unacceptable to real-time traffic such as
Voice over IP (VoIP).
This documents updates the packet formats for the Handover
Initiate (HI) and Handover Acknowledgement (HAck) messages to
Mobility Header Type.
Working Group Summary
This is a quick re-issue of the RFC for FMIP, based on discussion
in the WG that resulted in the desire to change the carrier protocol
from ICMP to MH. The change was initiated by the 3GPP2 community
who are the primary users of this protocol. It was viewed as a possible
change given the current deployment situation; later this change might
have been impossible.
Document Quality
There are multiple implementations of the FMIPv6 protocol. There
are also some folks wanting to deploy this protocol for fast
PMIPv6 handovers.
Personnel
Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko
RFC Editor Note
New text to be added to the current last paragraph in Introduction:
NEW:
Implementations of this specification MUST NOT send ICMPv6 HI and HAck
messages as defined in [RFC5268]. If implementations of this
specification receive ICMPv6 HI and HAck messages as defined in
[RFC5268], they MAY interpret the messages as defined in [RFC5268].
Please change in Section 3.3:
OLD:
The MN MUST process this PrRtAdv to configure a new Care-of Address on
the new subnet, and MUST send an FBU to PAR prior to switching to the
new link.
NEW:
The MN MUST process this PrRtAdv to configure a new Care-of Address on
the new subnet, and MUST send an FBU to the PAR prior to switching to
the new link.
And in Section 6.2.1.2
OLD:
Finally, the New Access Router can always refuse handover, in which
case it should indicate the reason in one of the available Code
values.
NEW:
Finally, the New Access Router can always refuse handover, in which
case it MUST indicate the reason in one of the available Code values.
In Section 11:
OLD:
The Subtype values 4 and 5 are deprecated and are marked as unassigned
for future allocations.
NEW:
The Subtype values 4 and 5 are deprecated but marked as unavailable
for future allocations.