Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
RFC 4140

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: Document Action: 'Hierarchical Mobile IPv6 mobility 
         management (HMIPv6)' to Experimental RFC 

The IESG has approved the following document:

- 'Hierarchical Mobile IPv6 mobility management (HMIPv6) '
   <draft-ietf-mipshop-hmipv6-05.txt> as an Experimental RFC

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

The IESG contact persons are Thomas Narten and Mark Townsley.

A URL of this Internet-Draft is:

Technical Summary
This document introduces extensions to Mobile IPv6 and IPv6 Neighbour
Discovery to allow for local mobility handling, that is, mobility
handled entirely within a visited domain. Hierarchical mobility
management reduces the amount of signalling between the Mobile Node,
its Correspondent Nodes and its Home Agent. The Mobility Anchor Point
described in this document can also be used to improve the performance
of Mobile IPv6 in terms of handover speed.

Working Group Summary
There was support for this document in the WG. Indeed, a primary
intent for chartering the mipshop WG was to complete both this
specification and the "Fast Handovers for Mobile IPv6" documents for
publication on the experimental track.
Protocol Quality
This document has been reviewed for the IESG by Thomas Narten and
Gabriel Montenegro.

RFC Editor Note:

Please change the last sentence in the next-to-last paragraph of
Section 12.1 from:


    This stops the mobile node from re-establishing a security
    association for the same RCoA.  This is not a major problem since
    both AH and ESP headers allow for 4 billion packets to be sent
    (the size of the sequence number field) using the same security

   This prevents the mobile node from being able to re-establish a
   security association for the same RCoA (i.e., to change session
   keys).  This is not a major problem, however, since the SA will
   typically only be used to protect signaling traffic when a MN
   moves, and not for the actual data traffic sent to arbitrary