Hierarchical Mobile IPv6 Mobility Management (HMIPv6)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, mipshop mailing list <firstname.lastname@example.org>, mipshop chair <email@example.com> 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: http://www.ietf.org/internet-drafts/draft-ietf-mipshop-hmipv6-05.txt
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: OLD: 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 association. NEW: 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 nodes.