Mobile IPv6 Fast Handovers
RFC 5568

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    mipshop mailing list <mipshop@ietf.org>, 
    mipshop chair <mipshop-chairs@tools.ietf.org>
Subject: Protocol Action: 'Mobile IPv6 Fast Handovers' to 
         Proposed Standard 

The IESG has approved the following document:

- 'Mobile IPv6 Fast Handovers '
   <draft-ietf-mipshop-rfc5268bis-01.txt> as a Proposed Standard

This document is the product of the Mobility for IP: Performance, 
Signaling and Handoff Optimization Working Group. 

The IESG contact persons are Jari Arkko and Ralph Droms.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mipshop-rfc5268bis-01.txt

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.