Skip to main content

Mobile IPv4 Fast Handovers
RFC 4988

Approval announcement
Draft of message to be sent after approval:

Announcement

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>, 
    mip4 mailing list <mip4@ietf.org>, 
    mip4 chair <mip4-chairs@tools.ietf.org>
Subject: Document Action: 'Mobile IPv4 Fast Handovers' to 
         Experimental RFC 

The IESG has approved the following document:

- 'Mobile IPv4 Fast Handovers '
   <draft-ietf-mip4-fmipv4-08.txt> as an Experimental RFC

This document is the product of the Mobility for IPv4 Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mip4-fmipv4-08.txt

Ballot Text

Technical Summary
 
  The document describes a new protocol designed to reduce the
  latency and packet loss experienced during handover. It does
  so by introducing new messages to be used among the Mobile 
  Node (MN), Previous Access Router (PAR) and New Access
  Router (NAR). The messages allow the MN to establish a
  binding at the PAR such that packets are forwarded to/from
  the NAR immediately after a handover. This avoids the long
  round-trip time to the home network that would be incurred
  by a standard Mobile IPv4 messsage flow.

Working Group Summary

  The document underwent working group last call in September 2006,
  and has been actively discussed and edited since then. Issues
  from the Last Call were resolved in -06, along with the issues from
  the AD review in -07.

Protocol Quality
 
  Pete McCann has reviewed this specification as a document
  shepherd, and Jari Arkko has reviewed this specification
  for the IESG.

Note to RFC Editor
 
  Please remove this sentence from the abstract: "Additional 
  mechanisms may be defined in the future versions of this 
  document."

  Please change in Section 4.2 (first paragraph)

  OLD:
   When sent in this "predictive" mode, the
   fields in the FBU are used as follows:

      "Home Address" field must be the PCoA (which can be either the
      Home Address or the co-located CoA)

      Home Agent field must be set to PAR's IP address

      Care-of Address field must be the NAR's IP address discovered via
      PrRtAdv message

      Destination IP address must be PAR's IP address

      Source IP address must be the PCoA (which can be either the Home
      Address or the co-located CoA)
   NEW:
    When sent in this "predictive" mode, the
    fields in the FBU MUST be used as follows:

      "Home Address" field is the PCoA (which can be either the
      Home Address or the co-located CoA)

      Home Agent field is set to PAR's IP address

      Care-of Address field is the NAR's IP address discovered via
      PrRtAdv message

      Destination IP address is the PAR's IP address

      Source IP address is the PCoA (which can be either the Home
      Address or the co-located CoA)


  Please change in Section 4.2 (fourth paragraph, below Figure 1)

   OLD:
    When sent in this "reactive" mode, the Destination IP address must be
    NAR's IP address;
   NEW:
    When sent in this "reactive" mode, the Destination IP address MUST be
    
    NAR's IP address;

  Please delete Section 5.

  Please add this to the end of the Acknowledgment (Section 10):

   Sending FBU from the new link (i.e., reactive mode) is similar to
   using the extension defined in [draft-mip4-ro]; however, this 
   document also addresses movement detection and router discovery 
   latencies.

  Please change in Section 6.1

  OLD:
  Lifetime: The number of seconds remaining before binding
         expires.  MUST NOT exceed 10 seconds.
  NEW:
  Lifetime: The number of seconds remaining before binding
         expires.  This value MUST NOT exceed 10 seconds.

  Please change in Section 8:

  OLD:
   The HI and HAck messages need to be secured using a pre-existing
   security association between the access routers to ensure at least
   message integrity and authentication, and should also include
   encryption.
  NEW:
   The HI and HAck messages need to be secured using a pre-existing
   security association between the access routers to ensure at least
   message integrity and authentication, and should also include
   encryption. IPsec ESP SHOULD be used.

  Please change in Section 8 (paragraph 5):

  OLD:
   Hence, the extent of this
   vulnerability is small."
  NEW:
   Hence, the extent of this
   vulnerability is small. It is possible to trace the culprit MN 
   with an established security association at the access router.

  Please change the last paragraph in Section 3.

  OLD:
   .. These delays contribute to the handover performance...
  NEW:
   .. These delays contribute to the handover performance. See
   [fh-ccr] and Chapter 20, Chapter 22 in [mi-book] ...

  Please add to Section 10:

    Thanks to Francis Dupont and Hannes Tschofenig for the 
    GEN-ART and TSV-DIR reviews.

  Please add the following informational references:

   [fh-ccr] R. Koodli and C. E. Perkins., "Fast Handovers and Context   

   Transfers in Mobile Networks," ACM Computer Communications Review
   Special Issue on Wireless Extensions to the Internet, October 2001.

   [mi-book] R. Koodli and C. E. Perkins, "Mobile Internetworking 
   with IPv6: Concepts, Principles and Practices," John Wiley & Sons,
   June 2007.

RFC Editor Note